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Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Transaction  Processing  Special 
Interest  Group  (TPSIG)  of  the  Open  Systems  Environment  Implementors'  Workshop  (OIW). 

Text  In  this  part  has  been  approved  by  the  Plenary  of  the  above-mentioned  Workshop.  No  significant 
technical  change  has  occurred  in  this  part  since  It  was  previously  presented. 

This  part  is  submitted  as  camera-ready  material.  Redline  and  Strikeout  were  not  used  in  this  text.  If  you 
have  any  questions  regarding  this  part,  please  call  the  TP  SIG  Chair. 
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INTRODUCTION 

The  aim  of  Open  Systems  Interconnection  is  to  allow,  with  a  minimum  of  technical  agreement  outside  the 
interconnection  standards,  the  interconnection  of  computer  systems: 

a.  from  different  manufacturers. 

b.  under  different  management. 

c.  of  different  levels  of  complexity. 

d.  of  different  technologies. 

Transaction  Processing  is  concerned  with  identifiable  information  which  can  t>e  related  as  transactions, 
which  may  involve  two  or  more  Open  Systems.  In  the  framework  of  Open  Systems  Interconnection  (OSI) 
a  transaction  is  defined  as  "a  set  of  related  operations  characterized  by  four  properties:  atomicity, 
consistency,  isolation  and  durability." 

The  definition  highlights  that  a  distributed  transaction  is  more  than  a  simple  exchange  of  messages,  but 
that  the  exchanges  fomn  a  protected  indivisible  set. 

This  multi-part  document  contains  the  complete  specification  of  the  six  profiles  identified  in  M-IT-02  and 
TR  10000. 

Part  1  contains  the  taxonomy  for  the  OSI  TP  profiles. 

Part  2  contains  the  specification  of  the  support  of  OSI  TP  APDUs  for  each  of  the  profiles  specified  in 
Parts  5  to  10. 

Part  3  contains  the  specification  of  the  support  of  the  CCR  APDUs  for  each  of  the  profiles  specified  in 
Part  5  to  10. 

Part  4  contains  the  specification  of  the  support  of  ACSE.  Presentation  and  Session  APDUs  for  each  of 
the  profiles  specified  in  Part  5  to  10. 

Parts  5  to  10  specify  the  six  profiles  which  are  defined,  based  on  the  OSI  TP  standard.  These  six  parts 
make  reference  to  Parts  2  to  4. 
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Information  Technology  -  Open  Systems  Interconnection  -  International  Standardized  Profiles 
12061-1:  OSI  Distributed  Transaction  Processing. 

Parti  INTRODUCTION 


1.  SCOPE 

Part  I  of  this  document  introduces  the  overall  structure  of  the  specification  of  the  OSI  TP  profiles. 
This  includes: 

a)  the  identification  of  the  Transaction  Processing  profiles  defined  in  this  document,  together 
with  the  Transaction  Processing  Profiles  Tree; 

b)  the  identification  of  the  various  Parts  which  constitute  this  document; 

c)  the  list  of  the  references  to  other  standards  relevant  to  the  definition  of  the  OSI  TP  profiles; 

d)  the  definitions  and  abbreviations  used  through  the  various  parts  of  this  document. 

2.  NORMATIVE  REFERENCES 

The  following  documents  contain  provisions  which,  through  reference  in  this  text,  constitute 
provisions  of  this  part  of  ISO/I  EC  ISP  1 2061 .  At  the  time  of  publication,  the  editions  indicated 
were  valid.  All  documents  are  subject  to  revision,  and  parties  to  agreements  based  on  this  part 
of  ISO/IEC  ISP  12061  are  warned  against  automatically  applying  any  more  recent  editions  of  the 
documents  listed  below,  since  the  nature  of  references  made  by  ISPs  to  such  documents,  is  that 
they  may  be  specific  to  a  particular  edition.  Members  of  I  EC  and  ISO  maintain  registers  of 
currently  valid  International  Standards  and  ISPs,  and  CCITT  maintains  published  editions  of  its 
current  Recommendations. 

The  following  ISO  standards  contain  provisions  for  the  definition  of  Transaction  Processing 
profiles  and  are  referenced  in  this  document: 


ISO/IEC  83271 
ISO/IEC  DIS  8327-2 
ISO/IEC  8327  AM3 
ISO/IEC  8650 


Information  Processing  Systems  -  Open  Systems  Interconnection 
Basic  connection  oriented  session  protocol  specification 

Infomnation  Processing  Systems  -  Open  Systems  Interconnection 
Basic  connection  oriented  session  PICS  Proforma. 

Information  Processing  Systems-  Open  Systems  Interconnection  - 
Session.  Additional  resynchronisation  functionality. 

Information  Processing  Systems  -  Open  Systems  Interconnection 


Second  edition  to  be  published 
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ISO/IEC  DIS  8650-2 
ISO/IEC  8823:1988 
ISO/IEC  DIS  8823-2 
ISO/IEC  8823  AM5 
ISO/IEC  8825:1990 

ISO/IEC  9805-1:1990 

ISO/IEC  DIS  9805-2 
ISO/IEC  9805  AM2 
ISO/IEC  10026-1:1992 
ISO/IEC  10026-2:1992 
ISO/IEC  10026-3:1992 
ISO/IEC  DIS  10026-4 
ISO/IEC  11188-12 


Protocol  Specification  for  the  Association  Control  Service  Element. 

Information  Processing  Systems  -  Open  Systems  Interconnection  - 
PICS  Proforma  for  the  Association  Control  Service  Element. 

Information  Processing  Systems  -  Open  Systems  Interconnection  - 
Connection  Oriented  Presentation  Protocol  Specification. 

Information  Processing  Systems  -  Open  Systems  Interconnection  - 
Connection  Oriented  Presentation  PICS  Proforma. 

Information  Technology  -  Open  Systems  Interconnection  - 
Presentation.  Additional  resynchronisation  functionality. 

Information  Processing  Systems  -  Open  Systems  Interconnection  - 
Specification  of  Basic  Encoding  Rules  for  Abstract  Syntax  Notation 
One  (ASN.1). 

Information  Technology  -  Open  Systems  Interconnection  -  Protocol 
Specification  for  the  Commitment,  Concurrency  and  Recovery  service 
element. 

Information  Technology  -  Open  Systems  Interconnection  -  CCR  PICS 
Proforma. 

Information  Technology  -  Open  Systems  Interconnection  -  CCR. 
Session  mapping  changes. 

Information  Technology  -  Open  Systems  Interconnection  -  Distributed 
Transaction  Processing:  Model. 

Information  Technology  -  Open  Systems  Interconnection  -  Distributed 
Transaction  Processing:  Service  Definition. 

Information  Technology  -  Open  Systems  Interconnection  -  Distributed 
Transaction  Processing:  Protocol  Specification. 

Information  Technology  -  Open  Systems  Interconnection  -  Distributed 
Transaction  Processing:  PICS  Profomria 

Information  Technology  -  International  Standardized  Profile-  Common 
Upper  Layer  Requirements 


2  Currently  a  regional  workshop  document 


2 


Part  1 5  -  Transaction  Processing 
OSI  TP  Profiles 


December  1992  (Stable) 
PDISP  12061-1 


3.       DEFINITIONS  AND  ABBREVIATIONS 

The  definitions  and  abbreviations  in  this  document  not  listed  in  this  section  are  found  in  the  TP 
model  document  (ISO/IEC  10026-1). 


AS- 

Conformance  class  for  Application  Supported  Transaction 

CP- 

Conformance  class  for  Chained  Provider  Supported  Transaction  Branches 

UP- 

Conformance  class  for  Unchained  Provider  Supported  Transaction  Branches 

FU- 

Functional  Unit 

ISP- 

International  Standardized  Profile 

PDU- 

Protocol  Data  Unit 

PPDU- 

Presentation  Protocol  Data  Unit 

SPDU- 

Session  Protocol  Data  Unit 

The  following  notations  are  used  in  the  tables  contained  in  Parts  2  to  4  of  this  ISP: 

1)  The  Item  Number  uniquely  identifies  each  capability,  parameter  or  field  within  the 
tables. 

2)  The  Parameter  column  provides  the  name  of  each  PDU  parameter. 

3)  The  Base  Standard  Status  column  indicates  static  requirements  as  defined  by  the 
base  standard  PICS  Proforma. 

The  notation  used  in  this  column  is  as  defined: 

-  in  the  OSI  TP  and  CCR  PICS  proforma  documents  for  the  OSI  TP  and  CCR 
related  tables; 

-  in  the  "Common  Upper  Layer  Requirement"  document  for  ACSE,  Presentation  and 
Session  related  tables. 

However,  as  the  ISP  is  not  intended  to  duplicate  the  information  contained  in  the 
documents  listed  above,  the  notation  has  been  simplified  as  follows: 

-  "C"  is  used  instead  of  any  "Cxxx",  where  xxx  is  an  integer. 

-  "O.n"  is  used  instead  of  any  "O.xxx",  where  xxx  is  an  integer. 

The  exact  definition  of  conditions  and  options  will  be  found  in  the  referenced 
documents. 

Note  that  the  "M"  and  "O"  notations  have  not  been  changed. 

Note  that  the  "D"  (default)  notation  may  be  used  in  this  column,  whilst  it  is  not  used 

in  the  PROFILE  Status  column  (included  within  the  M  notation). 

4)  The  Profile  ID  column,  if  present,  defines  how  this  parameter  is  used  by  a  specific 
profile. 

When  this  column  is  empty,  the  feature  applies  to  all  profiles  to  which  the  PDU 
applies. 

5)  The  Profile  Status  column  indicates  the  requirements  for  the  feature. 

These  requirements  are  valid  only  within  the  scope  of  a  specific  profile,  i.e.,  they 
apply  to  an  instance  of  an  implementation  operating  within  the  limits  specified  by  that 
profile.  For  instance,  the  notation  NA  used  for  some  feature  does  not  preclude  an 
implementation  front  supporting  more  than  one  profile. 

M  =   Mandatory.  The  feature  shall  be  supported,  i.e.  its  syntax  and  procedures 
shall  be  implemented  as  specified  in  the  base  standard  or  restricted  by  this 
ISP,  by  all  implementations  claiming  conformance  to  this  profile.  It  is  not 
necessary  that  a  mandatory  parameter  appears  in  all  instances  of 
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communication  when  either  a  default  value  has  been  specified,  or  this 
parameter  is  not  used  at  the  service  level. 

C  =    Conditional.  Any  feature  so  marked  must  be  implemented  under  the 

conditions  specified  in  the  profile  (e.g.  Mandatory,  Not  Applicable,  etc.,  for  a 
certain  instance  of  communication).  The  requirements  for  the  feature  then 
follow  the  rules  of  M,  NA,  etc. 

0  =   Optional.  This  is  an  optional  feature  in  the  base  standard.  It  is  left  to  the 

implementor  as  to  whether  this  feature  is  implemented.  Optional  features  for 
a  sender  need  not  be  implemented.  Optional  features  for  a  receiver  must  be 
recognized  and  may  be  processed  in  a  manner  consistent  with  the  base 
standard,  or  these  profiles.  If  implemented,  a  feature  will  be  subject  to 
conformance  testing. 

NA  =  Not  Applicable.  This  feature  is  not  defined  in  the  context  where  it  is 

mentioned  because  it  is  either  logically  or  physically  impossible  for  the  feature 
to  occur.  The  occurrence  of  this  feature  is  a  protocol  error.  It  will  be  handled 
as  specified  in  the  base  standard  or  this  ISP. 

1  =     Out  of  Scope.  This  is  an  optional  feature  of  a  base  standard.  However,  this 

feature  is  not  used  by  the  profile  nor  by  a  referencing  specification.  If  such  a 
feature  is  received  it  is  processed  according  to  local  procedures.  Local 
procedures  are  procedures  that  are  not  defined  by  any  base  standards  or 
profiles.  It  will  not  generate  a  protocol  error. 

There  are  presently  some  instances  where  features  marked  'M'  in  the  base 
standard  are  marked  T  in  this  profile.  This  has  been  done  only  because  the 
base  standard  PICS  are  not  yet  at  full  international  standard  status  and  it  is 
believed  that  the  markings  of  the  feature  will  change  during  progression  to  full 
international  standard  status.  It  is  intended  to  remove  all  such  inconsistencies 
with  the  base  standard  before  publication  of  this  ISP. 

•  =  U-ASE  defined.  This  is  an  optional  feature  of  a  base  standard.  This  feature 
may  or  may  not  be  used  by  a  referencing  specification.  How  it  is  used  is 
specified  by  the  referencing  specification.  When  a  default  value  is  given  in 
this  profile,  the  referencing  specification  may  choose  not  to  specify  any  value 
in  which  case,  the  default  value  applies.  A  default  value  is  specified  in 
parentheses  following  the  *,  e.g.,  *(l). 

O.N=  The  notation  O.N,  where  N  is  an  integer,  is  used  in  some  Status  Columns. 
This  notation  indicates  a  reference  to  a  unique  group  of  capabilities.  A  note 
(as  indicated  in  the  Notes  Column)  will  explain  the  exact  requirement  using 
one  of  the  following  forms: 

O.N  =  Support  of  exactly  one  of  these  items  is  required. 

O.N  =  Support  of  at  least  one  of  these  items  is  required. 
It  is  always  necessary  to  consult  the  corresponding  note  to  determine  which 
situation  applies. 

When  status  for  sending  and  receiving  values  differ,  they  will  be  separated  by  a 
slash,  with  the  sender  on  the  left  and  receiver  on  the  right.  If  they  are  the  same 
there  will  only  be  one  status  in  the  cell.  The  integer  suffix  to  a  status  refers  to  a 
condition  that  will  be  found  either  immediately  following  that  table,  or  following  an 
earlier  table  in  the  same  part  of  this  ISP. 
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6)  The  T/L/V  Allowed  column  specifies  the  range  of  types,  length,  or  values  this 
parameter  can  assume  or  contain.  This  column  can  have  multiple  definitions  based 
on  which  profile  is  being  described.  When  multiple  definitions  are  possible  this 
column  will  be  defined  in  conjunction  with  the  Profile  ID  column.  The  notation  {} 
denote  no  bits  in  the  parameter's  value. 

7)  The  Notes  column  points  to  notes  following  the  table. 
5.       TAXONOMY  STRUCTURE 

5.1 .    GUIDELINES  FOR  SPLITTING  UP  THE  PROFILES 

This  subclause  specifies  which  functional  units  combine  to  form  each  profile.  Refer  to  the 
appropriate  part  of  this  ISP  for  the  specification  of  how  a  specific  profile  uses  a  PDU  and  its 
parameters.  Profiles  are  identified  by  a  coding  method  which  consists  of  two  levels,  but  which 
can  easily  be  expanded  as  future  needs  warrant.  The  first  level  indicates  the  conformance  class. 
The  second  level  indicates  whether  polarized  or  shared  control  is  used.  The  levels  are  defined 
as: 

Level  one: 

1 .  -  Application  Supported  transactions. 

2.  -  Provider  supported  unchained  transactions. 

3.  -  Provider  supported  chained  transactions. 

Level  two: 

1 .  -  Polarized  control. 

2.  -  Shared  control. 

5.2     TRANSACTION  PROCESSING  PROFILES  TREE 

The  figure  hereafter  gives  the  Transaction  Processing  Profiles  tree: 


Transaction  Processing 

ATP 

Application  Supported  Transactions 

ATPl 

Polarized  Control 

ATPll 

Shared  Control 

ATPl  2 

Provider  Supported  Unchained  Transactions 

ATP2 

Polarized  Control 

ATP21 

Shared  Control 

ATP22 

Provider  Supported  Chained  Transactions 

ATP3 

Polarized  Control 

ATP31 

Shared  Control 

ATP32 

The  first  level  of  this  decomposition  (ATPx)  corresponds  to  the  definition  of  the  three 
conformance  classes  defined  in  the  OSI  TP  standard.  The  second  level  (ATPxy)  corresponds  to 
the  selection  between  Polarized  Control  and  Shared  Control  for  each  of  the  conformance 
classes.  The  conformance  classes  and  the  functional  units  that  compose  them  are  summarized 
in  the  following  list: 
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1 .  ATP-1 1  Application  Supported  Transactions  -  Polarized  Control: 
DIALOGUE  +  HANDSHAKE  +  POLARIZED  CONTROL 

2.  ATP-21  Provider  Supported  Unchained  Transactions  -  Polarized  Control: 
DIALOGUE  +  HANDSHAKE  +  POLARIZED  CONTROL  +  COMMIT  +  RECOVERY  + 
UNCHAINED  TRANSACTION 

3.  ATP-31  Provider  Supported  Chained  Transactions  -  Polarized  Control: 
DIALOGUE  +  HANDSHAKE  +  POLARIZED  CONTROL  +  COMMIT  +  RECOVERY  + 
CHAINED  TRANSACTION 

4.  ATP-1 2  Application  Supported  Transactions  -  Shared  Control: 
DIALOGUE  +  HANDSHAKE  (Optional)  +  SHARED  CONTROL 

5.  ATP-22  Provider  Supported  Unchained  Transaction  -  Shared  Control: 

DIALOGUE  +  HANDSHAKE  (Optional)  +  SHARED  CONTROL  +  COMMIT  +  RECOVERY  + 
UNCHAINED  TRANSACTION 

6.  ATP-32  Provider  Supported  Chained  Transactions  -  Shared  Control: 

DIALOGUE  +  HANDSHAKE  (Optional)  +  SHARED  CONTROL  +  COMMIT  +  RECOVERY  + 
CHAINED  TRANSACTION 


Since  the  Profile  ID  is  not  carried  as  a  protocol  parameter,  implementations  may  determine  the 
profile  governing  a  particular  instance  of  communication  by  the  TP  Functional  Units  selected  for 
that  dialogue. 

6.  CONFORMANCE 

This  part  of  ISO/I  EC  ISP  12061  states  requirements  upon  implementors  to  achieve  inter 
networking.  A  claim  of  conformance  to  one  of  parts  five  to  ten  of  this  ISP  is  a  claim  that  all 
requirements  in  the  relevant  base  standards  are  satisfied,  and  that  all  requirements  in  the 
relevant  parts  are  satisfied. 

Annexes  to  parts  two,  three  and  four  state  the  relationship  between  these  requirements  and 
those  of  the  base  standard. 

There  is  no  conformance  requirement  from  this  ISP  on  features  marked     in  the  annexes  of 
parts  two  and  four. 

Each  of  parts  five  to  ten  contain  specific  conformance  requirements  for  that  part. 
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INTRODUCTION 


The  aim  of  Open  Systems  Interconnection  is  to  allow,  with  a  minimum  of  technical  agreement 
outside  the  interconnection  standards,  the  interconnection  of  computer  systems 

a.  from  different  manufacturers, 

b.  under  different  management, 

c.  of  different  levels  of  complexity, 

d.  of  different  technologies. 

Transaction  Processing  is  concerned  with  identifiable  information  which  can  be  related  as 
transactions,  which  may  involve  two  or  more  Open  Systems.  In  the  framework  of  Open  Systems 
Interconnection  (OSI)  a  transaction  is  defined  as  "a  set  of  related  operations  characterized  by 
four  properties:  atomicity,  consistency,  isolation  and  durability." 

The  definition  highlights  that  a  distributed  transaction  is  more  than  a  simple  exchange  of 
messages,  but  that  the  exchanges  form  a  protected  indivisible  set. 

This  multi-part  document  contains  the  complete  specification  of  the  six  profiles  identified 
in  M-IT-02  and  TR  10000. 


Part  1  contains  the  taxonomy  for  the  OSI  TP  profiles. 


Part  2  contains  the  specification  of  the  support  of  OSI  TP  APDUs  for  each  of  the  profiles 
specified  in  Parts  5  to  10. 

Part  3  contains  the  specification  of  the  support  of  the  CCR  APDUs  for  each  of  the 
profiles  specified  in  Part  5  to  10. 

Part  4  contains  the  specification  of  the  support  of  ACSE,  Presentation  and  Session 
APDUs  for  each  of  the  profiles  specified  in  Part  5  to  1 0. 

Parts  5  to  10  specify  the  six  profiles  which  are  defined,  based  on  the  OSI  TP  standard. 
These  six  parts  make  reference  to  Parts  2  to  4. 


iii 
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1.  SCOPE  ,  . 

This  part  of  this  ISP  specifies  the  status  for  the  support  of  the  OS!  TP  protocol  for  the  profiles 
identified  in  Part  1  of  this  ISP. 


2.  NORMATIVE  REFERENCES 

The  references  listed  in  Part  1  of  this  ISP  apply. 

3.  DEFINITIONS  AND  ABBREVIATIONS 

The  definitions  and  abbreviations  contained  in  Part  1  of  this  ISP  apply  to  this  Part. 

4.  NOTATION 

The  notation  introduced  in  Part  1  of  this  ISP  applies  to  this  Part. 

5.  SUPPORT  OF  OSI  TP  PROTOCOL 

The  support  of  the  OSI  TP  protocol  is  as  described  in  Annex  A  (normative). 

The  structure  of  Annex  A  is  based  on  the  structure  of  Annex  A  of  ISO/IEC  10026-4,  in  particular 
in  the  numbering  of  the  clauses. 

When  a  clause  of  Annex  A  of  ISO/IEC  10026-4  is  not  relevant  to  the  profiles,  this  is  stated. 

6.  Conformance 

To  conform  to  the  OSI  TP  Protocol  used  in  any  of  the  profiles  in  this  ISP,  an  implementation  shall 
implement,  according  to  the  specifications  given  in  ISO/IEC  10026-3: 

1 .  All  the  mandatory  features  identified  in  Annex  A. 

2.  All  the  selected  optional  features,  as  identified  in  the  completed  TP  PICS. 
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ANNEX  A:  SUPPORT  OF  THE  OSI  TP  PROTOCOL  (Normative) 
A.I.  IDENTIFICATION 

No  restriction  is  applied  to  clause  A.I  of  ISO/IEC  1 0026-4  by  this  part  of  ISO/IEC  ISP  1 2061 . 
A.2.  CLAIMED  CONFORMANCE  TO  STANDARDS 

A.2.1.  ISO/IEC10026-3 

A.2.1 .1 .         VERSION  NUMBER(S) 

Answer  shall  be  "NONE". 

A.2.1 .2.         GLOBAL  CONFORMANCE  CLAIM 

Answer  shall  be  "YES". 

A.2.2.   ISO/IEC10026  AMENDMENTS 

Both  answers  shall  be  "NONE". 

A.2.3.  ISO/IEC  10026  TECHNICAL  CORRIGENDA 

Both  answers  shall  be  "NONE". 

Note:  At  the  time  of  the  approval  of  the  final  text  of  this  ISP,  no  Technical  Corrigenda  was 
approved  for  ISO/IEC  10026.  When  this  will  become  false,  the  present  ISP  will  be  connected 
accordingly. 
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A.2.4.  CONFORMANCE  CLASS(ES)  SUPPORTED 


Table  1  -  CONFORMANCE  CLASSES  SUPPORTED 


ITEM# 

CONFORMANCE  CLASSES 

ISO/IEC 
10026^ 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

Application  Transaction  Branches 

0 

M 

NA 

NA 

M 

NA 

NA 

2 

Chained  Provider  Supported  Transaction 
Branches 

0 

NA 

NA 

M 

NA 

NA 

M 

3 

Unchained  Provider  Supported  Transaction 
Branches 

0 

NA 

M 

NA 

NA 

M 

NA 

NOTES 


Conformance  to  more  than  one  profile  may  be  claimed  for  an  implementation.  For  example, 
an  implementation  that  conforms  to  profile  21  will  often  be  capable  of  conforming  to  the 
corresponding  Profile  1 1 . 
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A.3.  FUNCTIONAL  UNITS,  LIMITS  AND  PROTOCOL  MECHANISMS 
A.3.1 .  SUPPORT  OF  FUNCTIONAL  UNITS 

Table  2  -  SUPPORT  OF  FUNCTIONAL  UNITS 


ITEM# 

FUNCTIONAL  UNITS 

ISO/IEC  10026-4 

11 

21 

1 

31 

'ROFIL 
12 

:S 
22 

32 

NOTES 

AS 

CP 

UP 

1 

Dialoaue 

M 

M 

M 

M 

M 

M 

M 

M 

M 

2 

Shared  Control 

On 

O.n 

On 

NA 

NA 

NA 

M 

M 

M 

3 

Polarized  Control 

On 

On 

On 

M 

M 

M 

NA 

NA 

NA 

4 

Handshake 

O 

0 

O 

M 

M 

M 

O 

O 

O 

5 

Commit 

NA 

\A 

IVI 

NA 

M 

M 

NA 

M 

M 

6 

Chained  Transactions 

NA 

M 

NA 

NA 

NA 

M 

NA 

NA 

M 

7 

Unchained  Transactions 

NA 

NA 

M 

NA 

M 

NA 

NA 

M 

NA 

8 

Recovery 

NA 

M 

M 

NA 

M 

M 

NA 

M 

M 

A.3.2.   PROTOCOL  MECHANISMS  IMPLEMENTED 
A.3.2.1 .  CONCATENATION/SEPARATION 

Table  3  -  SUPPORT  FOR  CONCATENATION/SEPARATION 


ITEM# 

ROLE 

ISO/IEC 
10026^ 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

Concatenation 

O 

O 

O 

O 

0 

O 

0 

2 

Separation 

M 

M 

M 

M 

M 

M 

M 
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A.3.2.2.         ASSOCIATION  ESTABLISHMENT 


Table  4  -  ASSOCIATION  ESTABLISHMENT 


ITEM# 

ROLE 

ISO/IEC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

Initiator 

c 

0 

M 

M 

0 

M 

M 

1.2.4 

2 

Acceptor 

C 

O 

M 

M 

0 

M 

M 

1.3.4 

3 

Rejector 

0 

M 

M 

M 

M 

M 

M 

5.6 

NOTES 


1  When  the  commitment  is  supported,  then  the  implementation  must  be  able  to  support  both 
the  association  initiator  and  acceptor  role  in  order  to  be  able  to  perform  recovery  adequately. 

2  The  initiator  role  here  implies  being  capable  of  issuing  an  A-ASSOCIATE  request  and  being 
capable  of  receiving  an  A-ASSOCIATE  confirm. 

3  The  Acceptor  role  here  implies  being  capable  of  receiving  an  A-ASSOCIATE  indication  and 
being  capable  of  issuing  an  A-ASSOCIATE  response  with  a  positive  answer. 

4.  For  Profiles  1 1  and  12,  at  a  minimum,  the  association  establishment  initiator  role  or  the 
association  establishment  acceptor  role  shall  be  supported. 

5.  The  Rejector  role  here  implies  being  capable  of  receiving  an  A-ASSOCIATE  indication  and 
being  capable  of  issuing  an  A-ASSOCIATE  response  with  a  negative  answer. 

6.  Although  it  is  mandatory  to  be  able  to  reject  an  association,  note  that  in  some  particular 
environments  it  could  occur  that  the  reject  is  always  performed  by  some  lower  protocol 
machine  (e.g.  ACSE). 
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A.3.2.3.         SUPPORT  FOR  MANDATORY  AND  OPTIONAL  BIDDING 
Table  5  -  SUPPORT  FOR  MANDATORY  AND  OPTIONAL  BIDDING 


ITEM« 

ROLE 

ISO/IEC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

Initiator  with 
Bid  mandatory 

c 

C100 

M 

M 

ClOO 

M 

M 

2 

Initiator  with 
Bid  optional 

c 

C101 

O 

O 

C101 

O 

O 

3 

Responder  with 
Bid  mandatory 

C 

0102 

M 

M 

0102 

M 

M 

4 

Responder  with 
Bid  optional 

c 

C103 

M 

M 

0103 

M 

M 

100  If  the  Initatorof  an  association  role  is  supported(A.3.2.2/1)  then  O  else  NA. 


101  If  the  initiator  of  the  association  role  is  supported  (A.3.2.2/1)  then  M  else  NA. 

102  If  the  Acceptor  of  an  Association  role  is  supported(A.3 .2.2/2)  then  O  else  NA. 

103  If  the  Acceptor  of  an  Association  role  is  supported(A.3.2.2/2)  then  M  else  NA. 
A.3.2.4.  CONTENTION 


Table  6  -  SUPPORT  FOR  CONTENTION  MANAGEMENT 


ITEM# 

ROLE 

ISO/IEC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

Contention  Winner 

On 

O 

M 

M 

O 

M 

M 

1,2 

2 

Contention  Loser 

O.n 

o 

M 

M 

O 

M 

M 

1.2 

NOTES 

1 .  When  the  commitment  is  supported,  in  order  to  enable  channel  establishment  (initiator  or 
acceptor)  to  be  accepted,  it  is  required  to  be  able  to  support  both  the  contention  winner  and 
contention  loser  roles. 

2.  For  profiles  1 1  and  1 2,  at  least  one  of  the  contention  winner  and  contention  loser  roles  shall 
be  supported. 


7 


Part  15  -  Transaction  Processing 
TP 


December  1992  (Stable) 
PDISP  12061-2 


A.3.2.5.         BID  MECHANISM 

Table  7  -  SUPPORT  FOR  THE  BID  MECHANISM 


ITEM# 

ROLE 

ISO/IEC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

Initiator 

0 

0105 

M 

M 

0105 

M 

M 

1.3 

2 

Responder 

0 

C106 

M 

M 

0106 

M 

M 

2.3 

105  If  the  Contention  Loser  role  is  supported  (A.3.2.4/2)  then 

If  Associations  with  Bid  Mandatory  are  supported  (A.3.2.3/1  or  A.3.2.3/3) 
then  M  else  O 
else  NA 

1 06  If  the  Contention  Winner  role  is  supported  (A.3. 2.4/1 )  then  M  else  NA 
NOTES 

1 .  The  initiator  role  here  implies  being  capable  of  sending  a  TP-BID-RI APDU  and  being 
capable  of  receiving  a  TP-BID-RC  APDU. 

2.  The  responder  role  here  implies  being  capable  of  receiving  a  TP-BID-RI  APDU  and  being 
capable  of  sending  a  TP-BID-RC  APDU  with  a  positive  answer. 

3.  When  the  commitment  is  supported,  in  order  to  enable  channel  establishment  (initiator  and 
acceptor)  to  be  accepted,  it  is  required  to  be  able  to  support  both  the  bid  initiator  and  bid 
responder  roles. 

A.3.2.6.         DIALOGUE  ESTABLISHMENT 


Table  8  -  TP  DIALOGUE  ESTABLISHMENT 


ITEM* 

ROLE 

ISO/IEC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

Initiator 

On 

O 

O 

O 

0 

O 

O 

1.3 

2 

Acceptor 

On 

0 

0 

0 

O 

0 

O 

2.3 

3 

Rejector 

M 

M 

M 

M 

M 

M 

M 

NOTES 

1 .  The  initiator  role  here  implies  being  capable  of  sending  a  TP-BEGIN-DIALOGUE-RI  APDU 
and  being  capable  of  receiving  a  TP-BEGIN-DIALOGUE-RC  APDU. 
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2.  The  Acceptor  role  here  implies  being  capable  of  receiving  a  TP-BEGIN-DIALOGUE-RI APDU 
and  being  capable  of  sending  a  TP-BEGIN-DIALOGUE-RC  APDU  with  a  positive  answer. 

3.  For  each  of  the  profiles.at  least  one  of  the  Acceptor  or  initiator  roles  shall  be  implemented. 
A.3.2.7.         TRANSACTION  BRANCH  ESTABLISHMENT 


Table  9  -  TRANSACTION  BRANCH  ESTABLISHMENT 


ITEM# 

ROLE 

ISO/IEC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

Initiator 

0 

NA 

0107 

C107 

NA 

C107 

C107 

2 

Acceptor 

0 

NA 

C108 

C108 

NA 

C108 

C108 

107  If  the  implementation  is  capable  of  initiating  a  dialogue  (A.3.2.6/1)  then  M  else  NA. 

108  If  the  implementaion  is  capable  of  accepting  a  dialogue  (A.3.2.6/2)  then  M  else  NA. 
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A.3.2.8.         ROLES  IN  A  TRANSACTION  TREE  SUPPORTED 
Table  10  -  ROLES  IN  A  TRANSACTION  TREE  SUPPORTED 


ITEM# 

ROLE 

ISO/IEC 
1002&4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

Root  Node 

0 

NA 

0 

O 

NA 

O 

O 

1 

2 

Intermediate  Node 

c 

NA 

0 

0 

NA 

O 

O 

1 

3 

Leaf  Node 

c 

NA 

0109 

0109 

NA 

0109 

0109 

1 

109  If  capable  of  acting  as  an  intermediate  node  then  M  else  O. 
NOTES 

1 .  An  implementation  must  be  capable  of  acting  as  either  a  root,  an  intermediate  or  a  leaf 
node. 

A.3.2.9.         SUPPORT  FOR  RECOVERY 

This  clause  does  not  apply  to  profiles  1 1  and  1 2. 


Table  11  -  SUPPORT  FOR  RECOVERY 


ITEM* 

ROLE 

ISO/IEC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

One-Way 
recovery 

M 

NA 

M 

M 

NA 

M 

M 

2 

Two-Way 
Recovery 

O 

NA 

O 

O 

NA 

O 

O 
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A.4.  TP  PROTOCOL  -  GENERAL 

The  clause  A.4  in  ISO/IEC  10026-4  is  not  relevant. 

A.5.  TP  PROTOCOL  -  SUPPORT  OF  THE  DIALOGUE  FUNCTIONAL  UNIT 
A.5.1.   DIALOGUE  FU  APDUS 


Table  12  -  TP  APDUS  FOR  THE  DIALOGUE  FU 


ITEM# 

PROTOCOL  DATA  UNIT 

ISO/IEC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

TP-BEGIN-DIALOGUE-RI 

C 

CI  07/ 
M 

CI  07/ 
M 

CI  07/ 
M 

CI  07/ 
M 

CI  07/ 
M 

CI  07/ 
M 

1 

2 

TP-BEGIN-DIALOGUt- 
RC 

C 

tJU 
IW 

C107 

C107 

IW 

CI  07 

IW 

C107 

IW 

C107 

M/ 

IW 

C107 

o 

TP-FND-DIALOGLJE-RI 

Q 

M 

M 

NA 

M 

M 

NA 

4 

TP-END-DIALOGUE-RC 

c 

M 

M 

NA 

M 

M 

NA 

5 

TP-U-ERROR-RI 

M 

M 

M 

M 

M 

M 

M 

6 

TP-ABORT-RI 

M 

M 

M 

M 

M 

M 

M 

7 

TP-BID-RI 

C 

cm/ 

Clio 

M 

M 

cm/ 

Clio 

M 

M 

8 

TP-BID-RC 

C 

Clio/ 

cm 

M 

M 

Clio/ 

cm 

M 

M 

9 

TP-INITIALIZE-RI 

C 

C112/ 
M 

M 

M 

C112/ 
M 

M 

M 

3 

10 

TP-INITIALIZE-RC 

C 

M/ 

C112 

M 

M 

M/ 

C112 

M 

M 

4 

1 10  If  the  implementation  is  capable  of  receiving  a  Bid  (A.3. 2.5/2)  then  M  else  NA 

1 1 1  If  the  implementation  is  capable  of  initiating  a  Bid  (A.3.2.5/1)  then  M  else  NA 

1 12  If  the  implementation  is  capable  of  initiating  an  association  (A.3.2.2/1)  then  M  else  NA 

NOTES 

1 .   it  is  mandatory  for  every  implementation  to  receive  and  recognize  the  TP-BEGIN- 
DIALOGUE-RI  APDU  (ref  ISO/IEC  10026-3  13.1.2.1.C  and  13.1.2.1.f). 
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2.  It  Is  mandatory  for  every  implementation  to  be  capable  of  rejecting  a  TP-BEGIN-DIALOGUE- 
Rl  (ref  ISO/IEC  10026-3  13.1. 2.1f) 

3.  It  is  mandatory  for  every  implementation  to  receive  and  recognize  the  TP-INITIALIZE-RI 
APDU  (ref  ISO/IEC  10026-3  13.1.2.1.a). 

4.  It  is  mandatory  for  every  implementation  to  be  capable  of  rejecting  a  TP-INITIALIZE-RI 
APDU 


i 


* 
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A.5.2.  TP-BEGIN-DIALOGUE-RI  APDU 

A.5.2.1.         DETAIL  OF  THE  DIALOGUE  FIELD  OF  TP-BEGIN-DIALOGUE- 
Rl  APDU 

Table  13  -  TP-BEGIN-DIALOGUE-RI  for  Dialogue 


ITEM* 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Initiating-TPSU-Title 

0/M 

M 

See  Table  14 

2 

Redpient-TPSU-Title 

O/M 

M 

See  Table  14 

3 

Functional-Units 

D 

11 

M 

{0.4} 

12 

M 

11}  OR  {1.4) 

21 

M 

{0.3.4} 

22 

M 

{1.3}  or  {1,3,4} 

31 

M 

{0.2.4} 

32 

M 

{1.2}  or  {1,2.4} 

4 

Begin-Transaction 

C 

11,12,31.32 

NA 

21.22 

M 

5 

Confirmation 

D 

M 

6 

Correlator 

M 

M 

0.2**31-1 

7 

Last-Partner-Identifier 

O/M 

M 

0..2**31-1 

1 

8 

User-Data 

O/M 

M 

0..10K  octets-»- 

2 

NOTES 

1 .  The  Last-Partner-Identifier  is  marked  M  because  an  implementation  shall  be  able  to  support 
more  than  one  dialogue  or  channel  on  an  association. 

2.  The  receiver  shall  be  capable  of  receiving  at  least  1 0K  octets  of  user-data. 


13 


Part  1 5  -  Transaction  Processing 
TP 


December  1992  (Stable) 
PDISP  12061-2 


A.5.2.1.1.       DETAIL  OF  TPSU-TITLE  FIELDS  FOR  THE  DIALOGUE  FIELD 
OF  TP-BEGIN-DIALOGUE-RI  APDU 

Table  14  -  Detail  of  TPSU-TITLE  fields  for  the  dialogue  field  of  TP-BEGIN-DIALOGUE-RI 

APDU 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

TYPE 

STATUS 

PROFILE  ID 

STATUS 

JIUW  ALLOWED 

NOTES 

1 

T61  String 

O.n/M 

C113/M 

1.. 64  octets 

1 

2 

PrintableString 

O.n/M 

C113/M 

1..64  octets 

1 

3 

INTEGER 

O.n/M 

C113/M 

0..2**31-1 

1 

1 13  If  the  TPSU-TITLE  is  used  to  carry  a  RECIPIENT-TPSU-TITLE  value  then  M  else  O 
NOTES 

1 .  At  least  one  of  the  three  types  shall  be  supported  for  the  INITIATING-TPSU-TITLE. 
A.5.3.  TP-BEGIN-DIALOGUE-RC  APDU 

A.5.3.1.         DETAIL  OF  THE  DIALOGUE  FIELD  OF  TP-BEGIN-DIALOGUE- 
RC  APDU 

Table  15  -  TP-BEGIN-DIALOGUE-RC  for  Dialogue 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Functional- Units 

O/M 

M 

2 

Result 

D 

M 

3 

Diagnostic 

M 

M 

4 

Correlator 

M 

M 

0..2"31-1 

5 

User- Data 

O/M 

M 

0.1  OK  octets+ 

1 

NOTES 

1 .  The  receiver  shall  be  capable  of  receiving  at  least  1 0K  octets  of  user-data 
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A.5.4.  TP-END-DIALOGUE-RI  APDU 

This  APDU  does  not  apply  to  profiles  31  and  32. 

Table  16  -  TP-END-DIALOGUE-RI  for  Dialogue 


ITEM# 

ISO/lEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Confirmation 

D 

11.12,21.22 

M 

A.5.5.  TP-ABORT-RI  APDU 

A.5.5.1 .         DETAIL  OF  THE  USER  FIELD  OF  TP-ABORT-RI  APDU 

Table  17  -  TP-ABORT-RI,  for  user 


ITEM# 

ISO/lEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

User- Data 

0/M 

M 

0..10K  octets  + 

1 

NOTE 

1 .  The  receiver  shall  be  capable  of  receiving  at  least  1 0K  octets  of  user-data 

A.5.5.2.         DETAIL  OF  THE  PROVIDER  FIELD  OF  TP-ABORT-RI  APDU 


Table  18  -  TP-ABORT-RI,  for  provider 


ITEM* 

ISO/lEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

JIUV  ALLOWED 

NOTES 

1 

Provider-diagnostic 

M 

M 
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A.5.5.3.         TP-BID-RI APDU 

Table  19 -TP-BID-RI 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

VUy  ALLOWED 

NOTES 

1 

CO  R-Token-  Requested 

D 

11.12 

M 

False 

21,22,31,32 

M 

2 

Last-Partner-Identifier 

O/M 

M 

0.2**31 -1 

A.5.6.  TP-BID-RC  APDU 

Table  20  -  TP-BID-RC 

ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Result 

D 

M 

A.5.7.  TP-INITIALIZE-RI  APDU 

Table  21  -  TP-INITIALIZE-RI 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Protocol-Version 

D 

M 

{version  1) 

2 

Contention- Winner-Assignment 

D 

M 

3 

Bid- Mandatory 

D 

M 

4 

Recovery-Context-Handle 

C 

11,12 

1 

21.22,31,32 

O/M 

1..64  octets 

1 

NOTES 

1  It  is  optional  to  send  a  RECOVERY-CONTEXT-HANDLE  (RCH)  as  the  sender  may  have  no 
use  for  it.  It  is  mandatory  to  receive  an  RCH  and  be  able  to  send  it  on  the  TP-RECOVER-RI 
APDU. 
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A.5.8.  TP-INITIALIZE-RC  APDU 

Table  22  -  TP-INITIALIZE-RC 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Protocol- Version 

D 

M 

{version  1} 

2 

Reoovery-Context-Handle 

O/M 

11,12 

1 

21.22.31,32 

O/M 

1..64  octets 

1 

3 

Diaqnostic 

O/M 

M 

NOTES 

1    It  is  optional  to  send  a  Recovery-Context-Handle  (RCH)  as  the  sender  may  have  no  use  for 
it.  It  is  mandatory  to  receive  an  RCH  and  be  able  to  send  it  on  the  TP-RECOVER-RI  APDU. 
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A.6.  SUPPORT  OF  THE  SHARED  CONTROL  FUNCTIONAL  UNIT 
A.6.1 .  SHARED  CONTROL  FUNCTIONAL  UNIT  APDUS 

This  clause  does  not  apply  to  profiles  1 1 . 21  and  31 . 


Table  23  -  TP  APDUs  for  the  SHARED  Control  FU 


ITEM« 

PROTOCOL  DATA  UNITS 

ISO/IEC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

TP-U-ERROR-RG 

M 

NA 

NA 

NA 

M 

M 

M 
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A.7.  SUPPORT  OF  THE  POLARIZED  CONTROL  FUNCTIONAL  UNIT 

This  clause  does  not  apply  to  profiles  1 2,  22  and  32.. 

A.7.1 .   POLARIZED  CONTROL  FUNCTIONAL  UNIT  APDUS 


Table  24  -  TP  APDUs  for  the  Polarized  Control  FU 


ITEM# 

PROTOCOL  DATA  UNITS 

ISO/lEC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

TP-GRANT-CONTROL-RI 

M 

M 

M 

M 

NA 

NA 

NA 

2 

TP-REQUEST-CONTROL-RI 

M 

M 

M 

M 

NA 

NA 

NA 
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A.8.  SUPPORT  OF  THE  HANDSHAKE  FUNCTIONAL  UNIT 


This  clause  applies  to  all  profiles. 

A.8.1.  HANDSHAKE  FUNCTIONAL  UNIT  APDUS 

Table  25  -  TP  APDUs  for  the  Handshake  FU 


ITEM* 

PROTOCOL  DATA  UNITS 

ISO/IEC 
10026^ 

PROFILES 

11 

21 

31 

12 

J2  

32 

NOTES 

1 

TP-HANDSHAKE-RI 

M 

M 

M 

M 

C114 

C114 

C114 

_2  

3 

TP-HANDSHAKE-RC 

M 

M 

M 

M 

C114 

0114 

0114 

TP-HANDSHAKE-AND-GRANT- 
CONTROL-RI 

C 

M 

M 

M 

NA 

NA 

NA 

4 

TP-HANDSHAKE-AND-GRANT- 
CONTROL-RC 

C 

M 

M 

NA 

NA 

NA 

114!f  the  Handshake  FU  is  implemented  (A.3.1/4)  then  M  else  NA 
A.8.2.  TP-HANDSHAKE-RI  APDU 


This  APDU  is  not  applicable  for  profiles  12,  22  and  32  when  the  handshake  FU  is  not 
implemented. 

Table  26  -  TP-HANDSHAKE-RI 


ITEM* 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Confirmation-Urgency 

c 

11,21,31 

NA 

12.22.32 

M 
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A.8.3.  TP-HANDSHAKE-AND-GRANT-CONTROL-RI  APDU 

This  APDU  does  not  apply  to  profiles  1 2,  22  and  32. 

Table  27  -  TP-HANDSHAKE-AND-GRANT-CONTROL-RI 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Confirmation-Urgency 

D 

11.21.31 

M 

A.9.  TP  PROTOCOL  -  SUPPORT  OF  THE  COMMIT  FUNCTIONAL  UNIT 

This  clause  applies  only  to  profiles  21 ,  22,  31  and  32. 
A.9.1 .  COMMIT  FUNCTIONAL  UNIT  APDUS 


Table  28  •  TP  APDUs  for  Commit  FU 


ITEM* 

PROTOCOL  DATA  UNITS 

ISO/IEC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

TP-PREPARE-RI 

c 

NA 

C115 

/cue 

C115 
/C116 

NA 

0115 
/C1 16 

C115 
/C1 16 

2 

TP-DEFER-RI 

c 

NA 

C115 
/C116 

C115 
/C116 

NA 

C115 
/C116 

C115 
/C1 16 

3 

TP-HEURISTIC-REPORT-RI 

c 

NA 

C116 
/C115 

C116 
/C115 

NA 

C1 16 
/C1 15 

C116 
/C1 15 

4 

TP-TOKEN-GIVE-RI 

M 

NA 

M 

M 

NA 

M 

M 

1 15  If  the  implementation  is  capable  of  initiating  a  dialogue  (A.3.2.6/1)  then  M  else  NA 

1 16  If  the  implementation  is  capable  of  accepting  a  dialogue  (A.3.2.6/2)  then  M  else  NA 
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This  APDU  does  not  apply  to  profiles  1 1  and  12. 

Table  29  -  TP-PREPARE-RI 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Data-Permitted 

C 

21.31 

M 

22,32 

NA 

A.9.2.  TP-DEFER-RI  APDU 

This  APDU  does  not  apply  to  profiles  1 1  and  12. 

Table  30  -  TP-DEFER-RI 

ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Type 

D 

22.32 

M 

End-Dialogue 

21.31 

M 

A.9.3.  TP-HEURISTIC-REPORT-RI  APDU 

This  APDU  does  not  apply  to  profiles  1 1  and  1 2. 

Table  31  -  TP-HEURISTIC-REPORT-RI 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

J  

Heuristic- Report 

D 

M 

December  1992  (Stable) 
PDISP  12061-2 
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A.9.4.  TP-TOKEN-GIVE-RI  APDU 

This  APDU  does  not  apply  to  profiles  1 1  and  12. 


Table  32  -  TP-TOKEN-GIVE-RI 


ITEM* 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Reason 

0 

M 

Regular,  Keep 

2 

Correlator 

M 

M 
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A.10.    TP  PROTOCOL  -  SUPPORT  OF  THE  RECOVERY  FUNCTIONAL  UNIT 

This  clause  applies  only  to  profiles  21 ,  22,  31  and  32. 

A.10.1.  RECOVERY  FUNCTIONAL  UNIT  APDUS 


Table  33  -  TP  APDUs  for  Recovery  FU 


ITEM# 

PROTOCOL  DATA  UNITS 

ISO/IEC 
10026-4 

ATP11 

ATP21 

ATP31 

ATP12 

ATP22 

ATP32 

NOTES 

1 

TP-BEGIN-DIALOGUE-RI 

M 

NA 

M 

M 

NA 

M 

M 

1 

2 

TP-BEGIN-DIALOGUE-RC 

M 

NA 

M 

M 

NA 

M 

M 

1 

3 

TP-BID-RI 

C 

NA 

M 

M 

NA 

M 

M 

1 

4 

TP-BID-RC 

C 

NA 

M 

M 

NA 

M 

M 

1.3 

5 

TP-RECOVER-RI 

M/C 

NA 

M 

/C1 17 

M 

/C1 17 

NA 

M 

/C1 17 

M 

/C1 17 

6 

TP-END-DIALOGUE-RI 

M 

NA 

M 

M 

NA 

M 

M 

7 

TP-TOKEN-PLEASE-RI 

C 

NA 

C1 18 

C118 

NA 

C118 

C118 

3 

8 

TP-INITIALIZE-RI 

M 

NA 

M 

M 

NA 

M 

M 

3 

9 

TP-INITIALIZE-RC 

M 

NA 

M 

M 

NA 

M 

M 

3 

10 

TP-TOKEN-GIVE-RI 

NA 

O 

O 

NA 

O 

O 

2 

117  If  the  recovery-context-handle  field  (A.5.7/4,  A.5.8/2)  is  supported  in  the  TP-INITIALIZE-RC 
and  TP-INITIALIZE-RI  APDUs  then  M  else  NA 

1 18  If  Two-Way  recovery  (A.3.2.9)  is  supported  then  M,  else  NA 
NOTES 

1  When  the  commitment  is  supported,  in  order  to  enable  channel  establishment  (initiator  or 
acceptor)  to  be  accepted,  it  is  required  to  be  able  to  support  both  the  bid  initiator  and  the  bid 
responder  roles. 

2  This  PDU  is  not  in  the  Recovery  FU  in  ISO/IEC  10026-4.  However  it  has  been  added  to  this 
ISP  as  required  for  support  of  Two-Way  recovery. 

3  This  APDU  is  specified  in  clause  A.5. 
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A.10.2.  TP-BEGIN-DIALOGUE-RI APDU 

A.10.2.1.       DETAIL  OF  THE  CHANNEL  FIELD  OF  TP-BEGIN-DIALOGUE- 
RI  APDU 

This  table  does  not  apply  to  profiles  1 1  and  12. 


Table  34  -  TP-BEGIN-DIALOGUE-RI  (Recovery  FU) 


ITEM# 

ISO^EC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Functional-Units 

0 

M 

15) 

2 

Correlator 

M 

M 

0.2**31-1 

3 

Channel-Utilization 

0 

M 

one-way-recovery 

0 

two-way-recovery 

4 

Lxist-Partner-ldentifier 

0/M 

M 
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A.10.3.  TP-BEGIN-DIALOGUE-RC  APDU 

A.10.3.1.        DETAIL  OF  THE  CHANNEL  FIELD  OF  TP-BEGIN-DIALOGUE- 
RC  APDU 

This  table  does  not  apply  to  profiles  1 1  and  12. 


Table  35  -  TP-BEGIN-DIALOGUE-RC  (Recovery  FU) 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Result 

D 

M 

2 

Diagnostic 

M 

M 

3 

Correlator 

M 

M 

0..2"31-1 

A.10.4.  TP-END-DIALOGUE-RI  APDU 

This  table  does  not  apply  to  profiles  1 1  and  12. 

Table  36  -  TP-END-DIALOGUE-RI  (Recovery  FU) 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Confirmation 

D 

M 

False 

A.10.5.  TP-BID-RI  APDU 

This  table  does  not  apply  to  profiles  1 1  and  1 2. 

Table  37  -  TP-BID-RI  (Recovery  FU) 


ITEM« 

ISO/lEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

VL/y  ALLOWED 

NOTES 

1 

CCR-Tokens-Requested 

M 

M 

2 

Last-  Partner-  Identifier 

O/M 

M 

0..2"31-1 
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A.10.6.  TP-RECOVER-RI APDU 

This  APDU  does  not  apply  to  profiles  1 1  and  12. 


Table  38  •  TP-RECOVER-RI  APDU 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Reoovery-Context-Handle 

M 

M 

1..64  octets 

A.1 0.7.  TP-TOKEN-GI VE-RI  APDU 

Table  39  -  TP-TOKEN-GIVE-RI 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/LV  ALLOWED 

NOTES 

1 

Reason 

D 

M 

Two-Way-recovery 

2 

Correlator 

C 

M 

NOTES 


This  table  is  not  in  ISO/IEC  10026-4.  However  it  has  been  added  to  this  ISP  as  required  for 
support  of  Two-Way  recovery. 
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Introduction 


The  aim  of  Open  Systems  Interconnection  is  to  allow,  with  a  minimum  of  technical  agreement 
outside  the  interconnection  standards,  the  interconnection  of  computer  systems 

a.  from  different  manufacturers, 

b.  under  different  management, 

0.      of  different  levels  of  complexity, 
d.     of  different  technologies. 

Transaction  Processing  is  concerned  with  identifiable  information  which  can  be  related  as 
transactions,  which  may  involve  two  or  more  Open  Systems.  In  the  framework  of  Open  Systems 
Interconnection  (OSI)  a  transaction  is  defined  as  "a  set  of  related  operations  characterized  by 
four  properties:  atomicity,  consistency,  isolation  and  durability." 

The  definition  highlights  that  a  distributed  transaction  is  more  than  a  simple  exchange  of 
messages,  but  that  the  exchanges  form  a  protected  indivisible  set. 

This  multi-part  document  contains  the  complete  specification  of  the  six  profiles  identified 
in  M-IT-02  and  TR  10000. 


Part  1  contains  the  taxonomy  for  the  OSI  TP  profiles. 


Part  2  contains  the  specification  of  the  support  of  OSI  TP  APDUs  for  each  of  the  profiles 
specified  in  Parts  5  to  1 0. 

Part  3  contains  the  specification  of  the  support  of  the  CCR  APDUs  for  each  of  the 
profiles  specified  in  Part  5  to  10. 

Part  4  contains  the  specification  of  the  support  of  ACSE,  Presentation  and  Session 
APDUs  for  each  of  the  profiles  specified  in  Part  5  to  10. 

Parts  5  to  10  specify  the  six  profiles  which  are  defined,  based  on  the  OSI  TP  standard. 
These  six  parts  make  reference  to  Parts  2  to  4. 
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1.  SCOPE 

This  part  of  this  ISP  specifies  the  status  for  the  support  of  the  CCR  protocol  for  the  profiles 
identified  in  Part  1  of  this  ISP. 

2.  NORMATIVE  REFERENCES 

The  references  listed  in  Part  1  of  this  ISP  applies. 

3.  DEFINITIONS  AND  ABBREVIATIONS 

The  Definitions  and  Abbreviations  listed  in  Part  1  of  this  ISP  applies. 

4.  NOTATION 

The  notation  described  in  PART  1  of  this  ISP  Applies. 

5.  SUPPORT  OF  CCR  APDUs 

Annex  A  specifies  the  support  of  CCR  protocol. 

It  applies  to  profiles  21 ,  22, 31  and  32.  It  does  not  apply  to  profiles  1 1  and  12. 

6.  CONFORMANCE 

To  conform  to  the  OSI  CCR  protocol  used  in  any  of  the  profiles  defined  in  this  ISP,  an 
implementation  shall  implement,  according  to  the  specifications  given  in  ISO/IEC  9805: 

•  All  mandatory  features  identified  in  Annex  A. 

•  All  selected  optional  features,  as  identified  in  the  completed  CCR  PICS. 
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ANNEX  A:  CCR  PDU  Supports  (Normative)  

Temporary  Editor's  Note:  This  curent  Annex  A  is  based  on  a  version  of  tlie  CCR  PICS  Profomria 
which  is  based  on  Version  1  of  the  CCR  protocol.  It  is  expected  that  the  CCR  PICS  Proforma  will 
be  aligned  to  Version  2.  This  part  of  the  OSI  TP  ISP  will  be  updated  accordinly  during  the  DISP 
ballot  period.  Would  the  CCR  PICS  Proforma  not  be  aligned  on  time,  the  necessary  material  will 
be  inserted  in  the  OSI  TP  ISP. 

A.1  DATE  OF  STATEMENT 

No  restrictions  applied  to  clause  A.I  of  ISO/IEC  9805-2  by  this  ISP. 
A.2  IMPLEMENTATION  DETAILS 

No  restrictions  applied  to  clause  A.2  of  ISO/IEC  9805-2  by  this  ISP. 
A.3  ISO/IEC  9805-1 

The  answer  shall  be  "Version  2". 

A.4  AMENDMENTS  IMPLEMENTED 

Table  1  •  AMENDMENTS  IMPLEMENTED 


ITEM« 

Amendment 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

ISO/IEC  9805-1  Amendment  1 

NA 

NA 

NA 

NA 

NA 

NA 

2 

ISO/IEC  9805-1  Amendment  2 

NA 

M 

M 

NA 

M 

M 

A.5  TECHNICAL  CORRIGENDA  IMPLEMENTED 


The  answer  shall  be  "None". 

At  the  time  of  approval  of  the  final  text  of  this  ISP  no  technical  corrigenda  was  approved  for 
ISO/IEC  9805.  When  this  condition  changes,  the  present  ISP  will  be  amended. 

A.6  GLOBAL  STATEMENT  OF  CONFORMANCE 


A.6.1  MANDATORY  FEATURES  IMPLEMENTED 


The  answer  shall  be  "Yes". 
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A.7  INITIATOR/RESPONDER  CAPABILITIES 

A.7.1  ATOMIC- ACTION-BRANCH  ESTABLISHMENT 


Table  2  -  ATOMIC-ACTION-BRANCH  ESTABLISHMENT  BY  PROFILE 


ITEM# 

Roles 

ISO/IEC 
9805-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

SUPERIOR 

O 

NA 

0101 

0101 

NA 

0101 

0101 

1 

2 

SUBORDINATE 

o 

NA 

0102 

0102 

NA 

0102 

0102 

1 

3 

MASTER 

o 

NA 

0103 

0103 

NA 

0103 

0103 

101  If  capable  of  acting  as  a  root  node  or  intermediate  node  then  M  else  I. 

102  If  capable  of  acting  as  a  leaf  node  or  intermediate  node  then  M  else  I. 

103  If  capable  of  acting  as  a  root  node  then  M  else  I. 
NOTES 

1 .  At  least  one  of  the  superior  or  subordinate  roles  must  be  implemented. 

A.7.2  SUPPORT  FOR  THE  CONCATENATION  MECHANISM 


Table  3  -  SUPPORT  FOR  THE  CONCATENATION  MECHANISM 


ITEM# 

Roles 

ISO/IEC 
9805-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

SENDER 

O 

NA 

O 

M 

NA 

O 

M 

2 

RECEIVER 

M 

NA 

M 

M 

NA 

M 

M 

Tempoary  note  The  detail  of  the  markings  for  row  1 ,  sender  role  may  require  further  study.  A 
draft  technical  corrigendum  to  ISO/IEC  9805:1990  adds  procedures  for  the  combined  use  of 
the  C-COMMIT  and  C-BEGIN  sen/ices,  and  the  C-ROLLBACK  and  C-BEGIN  services. 
Support  for  concatenation  for  these  combined  sen/ices  may  not  be  optional.  An  issue  is  that 
TP  makes  no  use  of  the  C-ROLLBACK  and  C-BEGIN  services.  This  issue  may  apply  to 
ISO/IEC  DIS  9805-2  (CCR  PICS  Proforma). 

A.7.3  OTHER  IMPLEMENTATION  CAPABILITIES 


No  restriction  is  applied  to  clause  A.7.3  of  ISO/IEC  9805-2  by  this  ISP. 
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A.8  CCR  PROTOCOL  -  GENERAL 

This  subclause  details  TP's  requirements  of  the  CCR  protocol.  The  protocol  tables  described 
below,  except  for  the  CCR  PDU  Usage  by  Profile,  do  not  apply  to  TP  profiles  1 1  and  1 2. 

A.9  CCR  PROTOCOL 
A.9.1  CCRPDUs 

This  table  specifies  the  support  level  of  each  PDU  with  respect  to  each  profile. 


Table  4  -  CCR  PDU  USAGE  BY  PROFILE 


ITEM* 

Protocol  Data  Units 

ISO/IEC 
9805-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

C-BEGiN-RI 

C 

NA 

C104 
/C105 

C104 
/C105 

NA 

C104 
/C105 

C104 
/C105 

2 

C-BEGIN-RC 

o/c 

NA 

C105 
/C104 

C105 
/C104 

NA 

C105 
/C104 

C105 
/CI  04 

3 

C-PREPARE-RI 

o/c 

NA 

0104 
/CI  05 

0104 

/C105 

NA 

C104 
/C105 

C104 
/CI  05 

4 

C-READY-RI 

c 

NA 

C105 
/CI  04 

C105 
/C104 

NA 

C105 
/C104 

C105 
/C104 

5 

C-COMMIT-RI 

c 

NA 

C104 
/C105 

C104 
/C105 

NA 

C104 
/C105 

C104 
/C105 

6 

C-COMMIT-RC 

c 

NA 

C105 
/C104 

C105 
/C104 

NA 

C105 
/C104 

C105 
/CI  04 

7 

C-ROLLBACK-RI 

M 

NA 

M 

M 

NA 

M 

M 

e 

C-ROLLBACK-RC 

M 

NA 

M 

M 

NA 

M 

M 

9 

C-RECOVER-RI 

M 

NA 

M 

M 

NA 

M 

M 

10 

C-RECOVER-RC 

M 

NA 

M 

M 

NA 

M 

M 

104.  If  capable  of  acting  in  the  role  of  superior  then  M,  else  NA. 

105.  If  capable  of  acting  in  the  role  of  subordinate  then  M,  else  NA. 
A.9.2  C-BEGIN-RI 


Table  5  -  C-BEGIN-RI 


BASE  STANDARD  ISO/IEC  9805-2 

PROFILE 

ITEM« 

PARAMETER 

STATUS 

PRORLE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Atomic  Action  Identifier 

M 

M 

See  Table  6 

2 

Branchd-Suffix  -  Octet  String 

0/M 

0/M 

1  ..  64  octets 

1 

Branch-Suffix  -  Integer 

O/M 

0/M 

0..2"31-1 

1 

User  Data 

0/M 

NA 

NOTES 
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1 .  At  least  one  of  these  forms  must  be  supported. 

9.2.1.      ATOMIC-ACTION  IDENTIFIER 

This  clause  provides  detail  about  the  Atomic-Action  Identifier  field  of  the  C-BEGIN  APDU. 


Table  6  -  ATOMIC-ACTION  IDENTIFIER  DETAIL 


Atomic-Action  Identifier  of  tfte 
C-BEGIN  APDU 

PROFILE 

ITEM* 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Master's  Name 
AE-Title-Form  1 
(Directory  name) 

C/M 

0/M 

1  ..  1024  octets 

1.2 

Master's  Name 
AE-TiUe-Form  2 
(Obiect  Id) 

C/M 

M 

1  ..  64  octets 

2 

ktomic  Action  Id.- 
Isuffix  -  Octet  String 

C/M 

C106/M 

1  ..  64  octets 

2 

ktomic  Action  Id.- 
Isuffix  -  Integer 

C/M 

C106/M 

0.2**31-1 

106  If  only  the  Master  role  is  supported  then  at  least  one  form  shall  be  supported,  otherwise  both 
forms  shall  be  supported. 

NOTES 

1 .  It  is  optional  to  be  able  to  generate  a  Master's  name  AE-TITLE-FORM-1  (RON),  but  it  is 
mandatory  to  be  able  to  propogate  it  when  received  from  a  superior  by  an  intermediate  node 

2.  The  maximum  length  of  the  Atomic-Action  Identifer  shall  be  1 024  octets  for  Form  1  (Directory 
Name)  and  64  octets  for  Form  2  (object  ID).  This  length  includes  both  Master's  Name  and 
suffix. 

A.9.3  C-BEGIN-RC 


Table  7  -  C-BEGIN-RC 


ISO/IEC  9805-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

User-data 

0/M 

NA 
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A.9.4  C-PREPARE-RI 

Table  8  -  C-PREPARE-Ri 


ISO/IEC  9805-2 

PROFILE 

1  ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L^  ALLOWED 

NOTES 

luser-data 

0/M 

M 

A.9.5  C-READY-RI 

Table  9  -  C-READY-RI 


ISO/IEC  9805-2 

PROFILE 

1     ITEM#  1 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

User-data 

0/M 

NA 

A.9.6  C-COMMIT-RI 

Table  10 -C-COMMIT-RI 


ISO/IEC  9805-2 

PROFILE 

1  ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/LA/  ALLOWED 

NOTES 

il 

User- Data 

0/M 

M 

A.9.7  C-COMMIT-RC 


Table  11  -  C-COMMIT-RC 


BASE  STANDARD  ISO/IEC  9805-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

TIUV  ALLOWED 

NOTES 

|l 

User-data 

0/M 

M 
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A.9.8  C-ROLLBACK-RI 

Table  12  -  C-ROLLBACK-RI 


ISQ/IEC  9805-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

User-data 

0/M 

M 

A.9.9  C-ROLLBACK-RC 

Table  13  -  C-ROLLBACK-RC 


ISO/IEC  9805-2 

PROFILE 

ITEM« 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

User-data 

0/M 

M 

A.9.10  C-RECOVER-RI 

Table  14 -C-RECOVER-RI 


BASE  STANDARD  ISO/IEC  9805-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Atomic  Action  Identifier 

M 

M 

See  Table  15 

2 

Branch  Identifier 

M 

M 

See  Table  16 

3 

Recovery  State 

M 

M 

See  Table  17 

4 

User  Data 

0/M 

M 
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A.9.10.1.  ATOMIC-ACTION  IDENTIFIER 

This  clause  provides  detail  about  the  Atomic-Action  Identifier  field  of  the  C-RECOVER  Rl  APDU. 


Table  15  -  ATOMIC-ACTION  IDENTIFIER  DETAIL 


Atomic-Action  identifier  of  tli* 
C-RECOVER-Ri  APDU 

PROFiLf  1 

ITEIM 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L7V  ALLOWED 

NOTES 

1 

Master's  Name 
AE-Tille-Form  1 
(Directory  name) 

C 

0/M 

1  ..  1024  octets 

1 

Master's  Name 
AE-TitJe-Form  2 
(Ottiect  Id) 

c 

M 

1  ..  64  octets 

1 

2 

Atomic  Action  Id.- 
Suffix  -  Octet  String 

c 

M 

1  ..  64  octets 

1 

Atomic  Action  Id.- 
iSuffix  -  Inteqer 

c 

M 

0..2"31-1 

NOTES 

1 .  The  maximum  length  of  the  Atomic-Action  Identifer  shall  be  1 024  octets  for  Form  1  (Directory 
Name)  and  64  octets  for  Form  2  (object  ID).  This  length  includes  both  Master's  Name  and 
suffix. 
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A.9.10.2.   BRANCH  IDENTIFIER 

This  clause  provides  detail  about  the  Branch  Identifier  field  of  the  C-RECOVER  Rl  APDU. 


Table  16  -  BRANCH  IDENTIFIER  DETAIL 


1 — 

Branch  Identifier  of  the 
C-RECOVER-RI  APDU 

PROFILE  1 

ITEM* 

PARAMETER 

STATUS 

PROFILE  10 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Superior's- Name 
AE-Title-Form  1 
(Directory  name) 

c 

0/M 

1  ..  1024  octets 

Superior's- Name 
AE-Title-Form  2 
(Object  Id) 

c 

M 

1  ..  64  octets 

1 

2 

Branch"  Suffix  - 
Octet  String 

c 

M 

1  ..  64  octets 

1 

Branch-  Suffix  - 
Integer 

c 

M 

0  ..2**31-1 

NOTES 

1 .  The  maximunfi  length  of  the  Branch  Identifer  shall  be  1024  octets  for  Form  1  (Directory 
Name)  and  64  octets  for  Form  2  (object  ID).  This  length  includes  both  Superior's  Name  and 
suffix. 
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A.9.10.3.  RECOVERY  STATE 

This  clause  provides  detail  about  the  RECOVERY-STATE  field  of  the  C-RECOVER  Rl  APDU. 

Table  17  -  RECOVERY-STATE 


Recovery-State  of  the 
C-RECOVER-RI  APDU 

PROFILE 

ITEM# 

STATE 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Commit 

0 

C101/C102 

2 

Ready 

0 

C102/C101 

A.9.11  C-RECOVER-RC 

Table  18  -  C-RECOVER-RC 


BASE  STANDARD  ISO/IEC  9805-2 

PROFILE 

iTEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Atomic  Action  Identifier 

M 

M 

See  Table  19 

2 

Branch  Identifier 

M 

M 

See  Table  20 

3 

Recovery  State 

M 

See  Table  21 

4 

User  Data 

0/M 

1^ 

11 


Part  15  -  Transaction  Processing 
CCR 


December  1992  (Stable) 
PDISP  12061-3 


A.9.1 1.1.  ATOMIC-ACTION  IDENTIFIER 

This  clause  provides  detail  about  the  Atomic-Action  Identifier  field  of  the  C-RECOVER  RC  APDU. 


Table  19  -  ATOMIC-ACTION  IDENTIFIER  DETAIL 


Atomic-Action  Identifler  of  the 
C-RECOVER-RC  APDU 

PROFILE 

ITEIM 

PARAMETER 

STATUS 

PRORLE  ID 

STATUS 

jnjy/  ALLOWED 

NOTES 

1 

Master's  Name 
AE-Titte-Form  1 
(Directory  name) 

C 

0/M 

1 ..  1024  octets 

1 

Master's  Name 
AE-Title-Form  2 
(Obiect  Id) 

c 

M 

1 ..  64  octets 

1 

Atomic  Action  Id.- 
Suffix  -  Octet  String 

c 

M 

1 ..  64  octets 

1 

Atomic  Action  Id.- 
Suffix  -  Integer 

c 

M 

0 ..  2**31-1 

NOTES 

1 .  The  maximum  length  of  the  Atomic  Action  Identifer  shall  be  1 024  octets  for  Form  1  (Directory 
Name)  and  64  octets  for  Form  2  (object  ID).  This  length  includes  both  Master's  Name  and 
suffix. 
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A.9.11.2.  BRANCH  IDENTIFIER 

This  clause  provides  detail  about  the  Branch  Identifier  field  of  the  C-RECOVER  RC  APDU. 


Table  20  -  BRANCH  IDENTIFIER  DETAIL 


Branch  Identifier  of  the 
C-RECOVER-RC  APDU 

PROFILE  1 

ITEM« 

PARAMETER 

STATUS 

PRORLE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Superior's- Name 
AE-Title-Form  1 
(Directory  name) 

c 

0/M 

1  ..  1024  octets 

1 

Superior's- Name 
AE-Tltle-Form  2 
(Object  Id) 

0 

M 

1  ..  64  octets 

1 

2 

Branch"  Suffix  - 
Octet  string 

C 

M 

1  ..  64  octets 

1 

Branch-  Suffix  - 
Integer 

0 

M 

0 ..  2**31-1 

NOTES 


1 .  The  maximum  length  of  the  Branch  Identifer  shall  be  1 024  octets  for  Form  1  (Directory 
Name)  and  64  octets  for  Form  2  (object  ID).  This  length  includes  both  Superior's  Name  and 
suffix. 

A.9.11.3.  RECOVERY  STATE 

This  clause  provides  detail  about  the  RECOVERY-STATE  field  of  the  C-RECOVER  RC  APDU. 


Table  21  -  RECOVERY-STATE 


Recovery-State  of  the 
C-RECOVER-RC  APOU 

PROFILE  1 

ITEII/I# 

STATE 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Done 

0 

C102 
^CIOI 

2 

Unknown 

0 

C101 
/C102 

3 

Retry-later 

M 

M 
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INTRODUCTION 

The  aim  of  Open  Systems  Interconnection  is  to  allow,  with  a  minimum  of  technical  agreement 
outside  the  interconnection  standards,  the  interconnection  of  computer  systems 

a.  from  different  manufacturers, 

b.  under  different  management, 

c.  of  different  levels  of  complexity, 

d.  of  different  technologies. 

Transaction  Processing  is  concerned  with  identifiable  information  which  can  be  related  as 
transactions,  which  may  involve  two  or  more  Open  Systems.  In  the  framework  of  Open  Systems 
Interconnection  (OS  I)  a  transaction  is  defined  as  "a  set  of  related  operations  characterized  by 
four  properties:  atomicity,  consistency,  isolation  and  durability." 

The  definition  highlights  that  a  distributed  transaction  is  more  than  a  simple  exchange  of 
messages,  but  that  the  exchanges  form  a  protected  indivisible  set. 

This  multi-part  document  contains  the  complete  specification  of  the  six  profiles  identified 
in  M-IT-02  and  TR  10000. 

Part  1  contains  the  taxonomy  for  the  OSI  TP  profiles. 

Part  2  contains  the  specification  of  the  support  of  OSI  TP  APDUs  for  each  of  the  profiles 
specified  in  Parts  5  to  1 0. 

Part  3  contains  the  specification  of  the  support  of  the  CCR  APDUs  for  each  of  the 
profiles  specified  in  Part  5  to  10. 

Part  4  contains  the  specification  of  the  support  of  Session  ,  Presentation  and 
ACSEAPDUs  for  each  of  the  profiles  specified  in  Part  5  to  10. 

Parts  5  to  10  specify  the  six  profiles  which  are  defined,  based  on  the  OSI  TP  standard. 
These  six  parts  make  reference  to  Parts  2  to  4. 
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Information  Technology  -  Open  Systems  Interconnection  - 
International  Standardized  Profile  12061-4:  OSI  Distributed 
Transaction  Processing. 

Part  4:  Support  of  SESSION,  PRESENTATION  AND  ACSE  PDUs 


1.  SCOPE 

This  part  of  this  ISP  specifies  the  status  for  the  support  of  the  Session,  Presentation  and  ACSE 
protocols  for  the  profiles  identified  in  Part  1  of  this  ISP. 

2.  NORMATIVE  REFERENCES 

The  references  listed  in  Part  1  of  this  ISP. 

3.  DEFINITIONS  AND  ABBREVIATIONS 

The  definitions  and  abbreviations  contained  in  Part  1  of  this  ISP  apply  to  this  part. 

4.  NOTATION 

The  notation  described  in  PART  1  of  this  ISP  Applies. 

5.  SUPPORT  OF  SESSION  SPDUs 

Annex  A  specifies  the  support  of  Session  protocol. 

6.  SUPPORT  OF  PRESENTATION  PPDUs 

Annex  B  specifies  the  support  of  Presentation  protocol. 

7.  SUPPORT  OF  ACSE  APDUs 

Annex  C  specifies  the  support  of  ACSE  protocol. 

8.  CONFORMANCE 

To  conform  to  the  OSI  ACSE  protocol  used  in  any  of  the  profiles  defined  in  this  ISP,  an 
implementation  shall  implement,  according  to  the  specifications  given  in  ISO/IEC  8650: 

•    All  mandatory  features  identified  in  Annex  C. 
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•  All  selected  optional  features,  as  identified  in  the  completed  ACSE  PICS. 

•  All  restrictions  as  specified  in  the  Common  Upper  Layer  Requirements 
ISP -ISO  11188-1. 

To  conform  to  the  OSI  Presentation  protocol  used  in  any  of  the  profiles  defined  in  this  ISP,  an 
implementation  shall  implement,  according  to  the  specifications  given  in  ISO/IEC  8823: 

•  All  mandatory  features  identified  in  Annex  B. 

•  All  selected  optional  features,  as  identified  in  the  completed  Presentation  PICS. 

•  All  restrictions  as  specified  in  the  Common  Upper  Layer  Requirements 
ISP -ISO  11188-1. 

To  conform  to  the  OSI  Session  protocol  used  in  any  of  the  profiles  defined  in  this  ISP,  an 
implementation  shall  implement,  according  to  the  specifications  given  in  ISO/IEC  8327: 

•  All  mandatory  features  identified  in  Annex  A. 

•  All  selected  optional  features,  as  identified  in  the  completed  Session  PICS. 

•  All  restrictions  as  specified  in  the  Common  Upper  Layer  Requirements 
ISP  -  ISO  11188-1. 
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ANNEX  A:  Session  PROTOCOL  PDUs  (Normative) 


This  subclause  details  TP's  requirements  on  the  Session  protocol.  The  reader  should  consult  the 
Upper  Layer  agreements  for  a  detailed  discussion  of  these  services.  This  ISP  only  specifies  PDU 
parameters  necessary  for  this  ISP. 

A.1  SUPPORTED  FUNCTIONS 


Table  1  -  SUPPORTED  FUNCTIONS 


BASE  STANDARD  ISO/IEC  8327-2 

PROFILE 

ITEM# 

CAPABIUTY 

STATUS 

PROFILE  ID 

STATUS 

NOTES 

1 

Kernel 

M 

M 

2 

Negotiated  Release 

O 

*(") 

3 

Half  Duplex 

O.n 

NA 

3 

4 

Duplex 

On 

M 

c 

Expedited  Data 

0 

•(') 

6 

Typed  Data 

0 

11.12 

21.22,31,32 

M 

7 

Capability  Data  Exchange 

c 

11,12 

21,22.31,32 

NA 

3 

8 

Minor  Synchronize 

0 

11,12 

21,22.31.32 

M 

9 

Symmetric  Synchronize 

0 

11,12 

•(1) 

21,22,31,32 

NA 

3 

10 

Major  Synchronize 

O 

-(I) 

11 

Resyncronize 

0 

11,12 

•(1) 

21,22.31.32 

M 

12 

Exceptions 

0 

NA 

1,3 

13 

Activity  Management 

0 

11,12 

•(1) 

21,22,31,32 

NA 

2.3. 

14 

Data  Separation 

c 

11,12 

21,22,31.32 

M 

NOTES 


1.  Exceptions  FU  cannot  be  negotiated  because  Half  Duplex  is  not  allowed. 

2.  Activity  Management  FU  cannot  be  negotiated  for  these  profiles  because  the  Data 
Separation  FU  does  not  allow  the  Activity  Management  FU  to  also  be  selected. 

3.  Succesfully  accepting  these  functional  units  is  a  protocol  error.  If  any  of  the  following 
Functional  Units  is  proposed  on  a  CN  SPDU  the  Functional  Unit  shall  not  be  accepted  and 
the  corresponding  bit  shall  be  set  to  zero  on  the  Accept  SPDU. 
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A.2  ISO  8327  Protocol  Versions  Implemented 


Table  2  -ISO  8327  PROTOCOL  VERSIONS  IMPLEMENTED 


BASE  STANDARD  ISO/IEC  83 

27  -2 

PROFILE 

ITEM# 

CAPABIUTY 

STATUS 

PROFILE  ID 

STATUS 

NOTES 

1 

Version  1 

0 

1 

2 

Version  2 

0 

M 

A.3  PROTOCOL  MECHANISMS 


Table  3-  PROTOCOL  MECHANISMS 


ISO/IEC  8327-2 

PROFILE 

ITEM# 

CAPABIUTY 

STATUS 

PROFILE  ID 

STATUS 

NOTES 

1 

Use  of  Transport  Expedited  Data 

O 

0 

2 

Reuse  of  Transport  Connection 

0 

•(I) 

3 

Basic  Concatenation 

M 

M 

4 

Extended  Concatenation 

0 

1 

5 

Segmentation 

0 

•(I) 

6 

Segmentation  of  Unlimited  User  Data 

0 

•(I) 
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A.4  INITIATOR/RESPONDER  CAPABILITIES 


Table  4  •  INITIATOR/RESPONDER  CAPABILITIES 


ISO/IEC  8327-2 

PROFILE 

ITEM# 

CAPABIUTY 

STATUS 

PROFILE  ID 

STATUS 

NOTES 

1 

Initiator 

0 

C101 

2 

Responder 

0 

M 

101 .  If  capable  of  initiating  an  Association  then  M,  else  I. 


A.5  SESSION  PROCEDURES  USAGE  BY  PROFILE 

This  table  specifies  the  supported  level  of  each  Session  PDU  with  respect  to  each  profile. 


Table  5  •  KERNEL  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY  PROFILE 


ITEM# 

Protocol  Data  Units 

ISO/IEC 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

Connect  (CN) 

c/c 

C103 
/M 

C103 
/M 

C103 
/M 

C103 
/M 

C103 
/M 

C103 
/M 

2 

Overflow  Accept(OA) 

c 

1 

1 

1 

1 

1 

1 

3 

Connect  Data  Overflow(CDO) 

c 

1 

1 

1 

1 

1 

1 

4 

Accept(AC) 

c/c 

C104 
/C103 

C104 
/C103 

C104 
/CI  03 

C104 
/C103 

C104 
/C103 

C104 
/CI  03 

5 

Refus©(RF) 

c/c 

M 

/C103 

M 

/CI  03 

M 

/C103 

M 

/CI  03 

M 

/C103 

M 

/C103 

6 

Finish(FN) 

o/c 

0/M 

O/M 

O/M 

O/M 

O/M 

O/M 
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Table  5  -  continued 


ITEM# 

Protocol  Data  Units 

ISO/IEC 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

7 

Disconnect(DN) 

O 

M 

/C105 

M 

/0105 

M 

/0105 

M 

/C105 

M 

/0105 

M 

/CI  05 

8 

Abort(AB) 

M 

M 

M 

M 

M 

M 

M 

9 

Abort  Accept(AA) 

O 

0106 

0106 

0106 

0106 

0106 

0106 

10 

Data  Transfer(DT) 

0/C 

M 

M 

M 

M 

M 

M 

11 

Prepare(PR) 

C/C 

0107 

0107 

0107 

0107 

0107 

0107 

103.  If  capable  of  initiating  an  Association  then  M,  else  I. 

104.  If  capable  of  responding  to  a  AARQ  APDU  then  M,  else  I. 

105.  If  capable  of  initiating  a  FINISH  then  M,  else  NA. 

106.  If  reusing  T-Connection  then  M,  else  I. 

107.  If  transport  expedited  available  then  M,  else  NA. 

Table  6  -  NEGOTIATED  RELEASE  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY  PROFILE 


 1 

ITEM  # 

Protocol  Data  Units 

ISO/lEC 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

Not  Finished(NF) 

O/M 

2 

Give  Tokens(GT) 

O 

1 

3 

Please  Tokens(PT) 

O/M 

* 

* 

• 

1 

NOTES 


1 .  These  PDUs  are  marked  *  in  this  table  because  the  Negotiated  Release  FU  is  marked  *  in 
Table  1 .  These  PDUs  may  be  used  else  where  in  different  ways. 
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Table  7  -  HALF  DUPLEX  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY  PROFILE 


ITEM# 

Protocol  Data  Units 

ISO/IEC 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

Give  Tokens(GT) 

0 

NA 

NA 

NA 

NA 

NA 

NA 

1 

2 

Please  Tokens(PT) 

0/M 

NA 

NA 

NA 

NA 

NA 

NA 

1 

NOTES 

1 .  These  PDUs  are  marke  NA  in  this  table  because  the  Half  Duplex  FU  is  marked  NA  in  Table 
1 .  These  PDUs  may  be  used  else  where  in  different  ways. 

DUPLEX  FUNCTIONAL  UNIT  PROCEDURES 

No  additional  SPDUs  (this  clause  is  present  for  completeness). 


Table  8  -  EXPEDITED  DATA  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY  PROFILE 


ITEM# 

Protocol  Data  Units 

ISO/IEC 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

Expedited  Data(EX) 

O/M 

* 

* 

• 
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Table  9  -  TYPED  DATA  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY  PROFILE 


ITEM# 

Protocol  Data  Units 

ISO/IEC 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

Typed  Data(TD) 

O/M 

• 

M 

M 

M 

M 

Table  10  -  CAPABILITY  DATA  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY  PROFILE 


ITEM« 

Protocol  Data  Units 

ISO/IEC 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

Capability  Data(CD)) 

O/M 

NA 

NA 

NA 

NA 

1 

I2 

Capability  Data  Ack(CDA) 

M/C 

NA 

NA 

* 

NA 

NA 

1 

NOTES 


1 .  Because  the  Capability  Data  FU  shall  never  be  selected  on  a  Session  Connection  for  Profiles 
21 ,  22,  31 ,  and  32,  the  Session  Protocol  Machine  will  generate  a  protocol  error  when  a  CD  or 
CDA  SPDU  is  received  in  these  profiles. 

Table  11  -MINOR  SYNCHRONIZE  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY  PROFILE 


ITEM# 

1 

Protocol  Data  Units 

ISO/IEC 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

Minor  Sync  Point(MIP) 

0 

M 

M 

M 

M 

2 

Minor  Sync  Point  Ack(MIA) 

0/C 

M 

M 

M 

M 

3 

Give  Tokens(GT) 

0 

M 

M 

* 

M 

M 

4 

Please  Tokens(PT) 

O/M 

* 

M 

M 

M 

M 
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Table  12  -SYMMETRIC  SYNCHRONIZE  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY 

PROFILE 


ITEM  # 

Protocol  Data  Units 

ISO/IEC 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

^tote8 

1 

Minor  Sync  Point(MIP) 

O 

* 

NA 

NA 

• 

NA 

NA 

1 

2 

Minor  Sync  Point  Ack(MIA) 

0/C 

NA 

NA 

NA 

NA 

1 

NOTES 


1 .  Because  the  Symmetric  Synchronize  FU  shall  never  be  selected  on  a  Session  Connection  for 
Profiles  21 ,  22,  31 ,  and  32,  the  MIP  and  MIA  SPDUs  have  been  marked  NA.  They  may  be 
used  differently  elsewhere. 


Table  13  -MAJOR  SYNCHRONIZE  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY 

PROFILE 


ITEM# 

Protocol  Data  Units 

ISO/IEC 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

^4ote8 

1 

Major  Sync  Point(MAP) 

0/M 

« 

• 

• 

2 

Major  Sync  Point  Ack(MAA) 

M/C 

* 

3 

Give  Tokens(GT) 

0 

1 

4 

Please  Tokens(PT) 

O/M 

* 

* 

* 

1 

5 

Prepare(PR) 

C/C 

1 

NOTES 


1 .  Because  the  Major  Synchronize  FU  has  been  marked  *  in  Table  1 ,  these  PDUs  have  been 
marked  *.  They  may  be  used  differently  elsewhere. 


Table  14  -RESYNCHRONIZE  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY  PROFILE 


ITEIM# 

Protocol  Data  Units 

ISO/iEC 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

RESYNCHRONIZE(RS) 

O/M 

M 

M 

M 

M 

1 

2 

RESYNCHRONIZE  Ack(RA) 

M/C 

M 

M 

M 

M 

1 

3 

Prepare(PR) 

c/c 

C107 

C107 

C107 

C107 

1 
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NOTES 

1 .   Because  the  ReSynchronize  FU  has  been  marked  in  Table  1  with  *  for  Profiles  1 1  and  12 
these  PDUs  have  been  marked  with  *  in  this  table.  They  may  be  used  differently  elsewhere. 


Table  15  -EXCEPTIONS  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY  PROFILE 


ITEM# 

Protocol  Data  Units 

ISO/IEC 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

Exception  Report(ER) 

O/M 

NA 

NA 

NA 

NA 

NA 

NA 

1 

2 

Exception  Data(ED) 

0/M 

NA 

NA 

NA 

NA 

NA 

NA 

1 

NOTES 


1 .  Because  the  ExceptionFU  shall  never  be  selected  for  a  Session  Connection,  the  Session 
Protocol  Machine  will  generate  a  protocol  error  when  an  ER  or  ED  SPDU  is  received. 


Table  16  -ACTIVITY  MANAGEMENT  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY 

PROFILE 


ITEM# 

Protocol  Data  Units 

ISO/IEC 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

Activity  Start(AS) 

O/M 

NA 

NA 

NA 

NA 

2 

2 

Activity  Resume(AR) 

O/M 

NA 

NA 

NA 

NA 

2 

3 

Activity  Interrupt(AI) 

O/M 

NA 

NA 

NA 

NA 

2 

4 

Activity  Interrupt  Ack(AIA) 

M/C 

NA 

NA 

NA 

NA 

2 

5 

Activity  Discard(AD) 

O/M 

NA 

NA 

NA 

NA 

2 

6 

Activity  Discard  Ack(ADA) 

M/C 

NA 

NA 

NA 

NA 

2 

7 

Activity  End(AE) 

O/M 

NA 

NA 

NA 

NA 

2 

8 

Activity  End  Ack(AEA) 

M/C 

NA 

NA 

NA 

NA 

2 

9 

Prepare(PR) 

c/c 

NA 

NA 

NA 

NA 

2,3 

10 

Give  Tokens(GT) 

O 

NA 

NA 

NA 

NA 

2,3 

11 

Please  Tokens(PT) 

O/M 

NA 

NA 

NA 

NA 

2.3 

12 

Give  Tokens  Confirm(GTC) 

O/M 

NA 

NA 

NA 

NA 

1,2 

13 

Give  Tokens  Confirm  Ack(GTA) 

O/M 

NA 

NA 

NA 

NA 

1,2 

NOTES 


1 .  The  Give  tokens  confirm  and  Ack  are  a  result  of  the  control  give  service  and  require  the 
activity  management  FU. 

2.  Because  the  Activity  Management  FU  shall  never  be  selected  on  a  Session  connection  for 
profiles  21 ,  22,  31  and  32,  the  Session  Protocol  Machine  will  generate  a  protocol  error  when 
the  SPDU  is  received  in  these  Profiles. 

3.  Because  the  Activity  Management  FU  has  been  marked  in  Table  1  with  *  or  NA  the  PDUs 
have  been  marked  with  *  or  NA  in  this  table.  They  may  be  used  differently  elsewhere. 
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A.6  SUPPORTED  PARAMETERS  OF  SESSION  PDUs. 
A.6.1  CONNECT  (CN)  SPDU 


Table  17  -  CONNECT  (CN)  SPDU 


ISO/IEC  8327-2 

PROFILE  1 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

PGI  Connection  Identifier 

1 

PGI  default  (absent) 

O/M 

2 

PGI  default  (empty) 

O/M 

3 

Calling  SS-User  Reference 

O/M 

4 

Common  Reference 

O/M 

5 

Additional  Reference  Info 

O/M 

PGI  Connect/Accept  Item 

6 

PGI  default  (absent) 

O/M 

7 

PGI  default  (empty) 

O/M 

8 

PGI  default  (not  empty) 

O/M 

M 

9 

Protocol  Options 

O/M 

l/M 

10 

TSOU-Maximum-size 

O/M 

l/M 

11 

Version  Number 

O/M 

M 

Version  2 

12 

Initial  Serial  Number 

O/M 

11,12 

21.22,31.32 

M 

13 

Token  Setting  Item 

O/M 

11,12 

21,22,31,32 

M 

|l4 

Second  Initial  Serial  Number 

C/C 

11.12 

C108 

21,22,31,32 

1 

1 
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Table  17  -  continued 


ISO/IEC  8327-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

Single  Items 

15 

Session  User  Requirements 

O/M 

M 

16 

Calling  Session  Selector 

O/M 

M 

17 

Called  Session  Selector 

O/M 

M 

18 

PGI  "User  Data" 

O/M 

M 

19 

Data  Overflow 

C/C 

1 

20 

PGI  "Extended  User  Data" 

C/C 

M 

108.     If  Symmetric-Sync  supported  then  0  else  I. 
NOTES 

1 .  Because  the  Symmetric  Synchronize  FU  shall  never  be  selected  for  a  Session  connection  for 
.    Profiles  21,  22,  31  and  32,  the  Session  Protocol  machine  will  ignore  the  Second  Initial  Serial 
Number  parameter  if  it  is  present  on  a  CN  SPDU  in  Profiles  21 ,  22,  31 ,  and  32. 


A.6.2  OVERFLOW  ACCEPT  (OA)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP. 
A.6.3  CONNECT  DATA  OVERFLOW  (CDO)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP. 
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A.6.4  ACCEPT  (AC)  SPDU 


Table  18  -  ACCEPT(AC)  SPDU 


ISO/IEC  8327-2 

PROFILE 

ITEM* 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

PGI  Connection  Identifier 

1 

PGI  default  (absent) 

O/M 

2 

PGI  default  (empty) 

0/M 

3 

Calling  SS-User  Reference 

O/M 

4 

Common  Reference 

O/M 

5 

Additional  Reference  Info 

O/M 

PGI  Connect/Accept  Item 

6 

PGI  default  (absent) 

O/M 

NA 

1 

7 

PGI  default  (empty) 

O/M 

NA 

1 

8 

PGI  default  (not  empty) 

O/M 

M 

9 

Protocol  Options 

C/M 

1 

10 

TSDU-Maximum-size 

O/M 

l/M 

11 

Version  Number 

C/M 

M 

Version  2 

12 

Initial  Serial  Number 

O/M 

11,12 

21.22.31.32 

M 

13 

Token  Setting  Item 

O/M 

11,12 

21.22.31.32 

M 

14 

Second  Initial  Serial  Number 

C/C 

11,12 

C108 

21,22.31.32 

1 

2 

Single  Items 

15 

Token  Item 

O/M 

O/M 

16 

Session  User  Requirements 

O/M 

M 

17 

Calling  Session  Selector 

O/M 

M 

18 

Called  Session  Selector 

O/M 

M 

19 

PGI  "User  Data" 

O/M 

M 

20 

Enclosure  Item 

C 
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NOTES 

1 .  Because  Session  Version  2  shall  be  selected,  the  Session  Protocol  Machine  will  generate  a 
protocol  error  when  the  PGI  Connect/Accept  item  is  absent  or  empty. 

2.  Because  the  Symmetric  Synchronize  FU  shall  never  be  selected  for  a  Session  connection  for 
Profiles  21,  22,  31  and  32,  the  Session  Protocol  Machine  will  ignored  the  Second  Initial 
Serial  Number  parameter  if  it  is  present  on  an  AC  SPDU  in  Profiles  21 ,  22,  31 ,  and  32. 

A.6.5  REFUSE  (RF)  SPDU 


Table  19  -  REFUSE  (RF)  SPDU 


ISOMEC  8327-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

PGI  default  (empty) 

0/1^ 

2 

PGI  default  (not  empty) 

0/M 

3 

Called  SS-User  Reference 

0/M 

4 

Common  Reference 

0/M 

5 

Additional  Reference  Info 

0/M 

Single  Items 

6 

Transport  Disconnect 

O/M 

0/M 

9 

Session  User  Requirements 

0/M 

M 

10 

Version  Number 

0/M 

M 

11 

Reason  Code 

0/M 

M 

12 

Enclosure  Item 

0 

A.6.6  FINISH  (FN)  SPDU 


Table  20  -  FINISH  (FN)  SPDU 


ISO/IEC  8327-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

HUM  ALLOWED 

NOTES 

1 

Transport  Disconnect 

0/M 

0/M 

2 

PGI  "User  Data" 

0/M 

M 

3 

Enclosure  Item 

c/c 
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A.6.7  DISCONNECT  (DN)  SPDU 

Table  21  -  DISCONNECT  (DN)  SPDU 


iSO/lEC  8327-2 

PF 

iOFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

PGI  "User  Data" 

0/M 

M 

2 

Enclosure  Item 

C/C 

• 

A.6.8  NOT  FINISHED  (NF)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP. 
A.6.9  ABORT  (AB)  SPDU 

Table  22  -  ABORT  (AB)  SPDU 


ISO/ICQ  8327-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Transport  Disconnect 

M 

M 

2 

Reflect  Parameter  Values 

0/M 

1 

3 

PGI  "User  Data" 

0/M 

M 

4 

Enclosure  Item 

c/c 

A.6.10  ABORT  ACCEPT  (AA)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP. 
A.6.11  DATA  TRANSFER  (DT)  SPDU 

Table  23  -  DATA  TRANSFER  (DT)  SPDU 


ISO/lEC  8327-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

User  Information  Field 

0/M 

M 

2 

Enclosure  Item 

c/c 

A.6.12  EXPEDITED  DATA  (EX)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP. 
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A.6.13  TYPED  DATA  (TD)  SPDU 


Table  24  -  TYPED  DATA  (TD)  SPDU 


ISO/IEC  8327-2 

PF 

iOFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Enclosure  Item 

C/C 

* 

2 

User  Information  Field 

0/M 

M 

A.6.14  CAPABILITY  DATA  (CD)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  In  profiles  1 1  and  12  is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21,22,31  and  32  is  prohibited 

A.6.15  CAPABILITY  DATA  ACK  (CDA)  SPDU 


This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  in  profiles  1 1  and  12  is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21,22,31  and  32  is  prohibited 
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A.6.16  GIVE  TOKENS  (GT)  SPDU 

This  PDU  is  not  used  by  Profiles  1 1  and  12. 

Table  25  -  GIVE  TOKENS  (GT)  SPDU 


ISO/iEC  8327-2 

PROFILE 

ITEM« 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

|l 

hroken  Item 

0/M 

M 

Minor  Sync 

Other  Tokens 

IpGI  'User  Data' 

C/C 

M 

P               HEndosure  Item 

C/C 

• 

A.6.17  PLEASE  TOKENS  (PT)  SPDU 

This  PDU  is  not  used  by  Profiles  11  and  12. 

Table  26  -  PLEASE  TOKENS  (PT)  SPDU 


ISO/IEC  8327-2 

PROFILE 

ITEAM 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

1 

Token  Item 

0/M 

M 

Minor  Sync 

NOTES  1 

• 

Other  Tokens 

2 

PGI  "User  Data' 

0/M 

M 

3 

Enclosure  Item 

C/C 
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A.6.18  MINOR  SYNC  POINT  (MIP)  SPDU 

This  PDU  is  not  used  by  Profiles  1 1  and  12. 

Table  27  -  MINOR  SYNC  POINT  (MIP)  SPDU 


ISO/IEC  8327-2 

PROFILE 

ITEHM 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/LA^  ALLOWED 

NOTES 

1 

Sync  Type  Item 

0/M 

M 

2 

Serial  Number 

M 

M 

3 

PGI  "User  Data" 

0/M 

M 

4 

Enclosure  Item 

C 

M 

A.6.19  MINOR  SYNC  POINT  ACK  (MIA)  SPDU 

This  PDU  is  not  used  by  Profiles  1 1  and  12. 

Table  28  •  MINOR  SYNC  POINT  ACK  (MIA)  SPDU 


ISO/IEC  8327-2 

PROFILE  1 

ITEM* 

PARAMETER 

STATUS 

PROFILE  !D 

STATUS 
M 

T/L/V  ALLOWED 

NOTES 

Serial  Number 

M 

PGI  "User  Data" 

0/M 

M 

Enclosure  Item 

0/0 

ft 

A.6.20  MAJOR  SYNC  POINT  (MAP)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP. 


A.6.21  MAJOR  SYNC  POINT  ACK  (MAA)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP. 
A.6.22  RESYNCHRONIZE  (RS)  SPDU 

This  PDU  is  not  used  by  TP  for  profiles  1 1  and  12. 
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Table  29  -  RESYNCHRONIZE  (RS)  SPDU 


ISO/IEC  8327-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES  1 

1 

Enclosure  Item 

C 

2 

Token  Setting  Item 

0/M 

M 

Minor  Sync 

• 

Other  Tokens 

3 

Resync  Type 

0/M 

M 

4 

Serial  Number 

0/M 

M 

5 

Second  Resync  Type 

0 

1 

6 

Second  Serial  Number 

0 

7 

PGI  "User  Data" 

0/M 

M 

A.6.23  RESYNCHRONIZE  ACK  (RA)  SPDU 


Table  30  RESYNCHRONIZE  ACK  (RA)  SPDU 


This  PDU  is  not  used  by  TP  for  profiles  1 1  and  1 2. 


1                       ISO/IEC  8327-2 

PROFILE  1 

ITEM« 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Enclosure  Item 

C 

2 

Token  Setting  Item 

0/M 

32 

M 

Minor  Sync 

Other  Tokens 

3 

Resync  Type 

0/M 

1 

4 

Serial  Number 

0/M 

M 

5 

Second  Resync  Type 

C/C 

1 

6 

Second  Initial  Serial  Number 

C/C 

1 

7 

PGI  "User  Data" 

0/M 

M 

19 


Part  15  -  Transaction  Processing 
Session 


December  1992  (Stable) 
PDISP  12061-4 


A.6.24  PREPARE  (PR)  SPDU 

Table  31  -  PREPARE  (PR)  SPDU 

This  PDU  is  not  used  by  TP  for  profiles  1 1  and  1 2. 


ITEM« 

ISO/IEC  8327-2 

PROFILE  1 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Prepare  Type 

M 

M 

2 

Resyrw  Type 

0 

1 

3 

Second  Resync  Type 

c 

1 

A.6.25  EXCEPTION  REPORT  (ER)  SPDU 


This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  prohibited 
A.6.26  EXCEPTION  DATA  (ED)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  prohibited 
A.6.27  GIVE  TOKENS  CONFIRM  (GTC)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  in  profiles  1 1  and  12  is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21 ,22,31  and  32  is  prohibited 

A.6.28  GIVE  TOKENS  CONFIRM  ACK  (GTA)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  in  profiles  1 1  and  12  is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21 ,22,31  and  32  is  prohibited 

A.6.29  ACTIVITY  START  (AS)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  in  profiles  1 1  and  12  is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21 ,22,31  and  32  is  prohibited 

A.6.30  ACTIVITY  RESUME  (AR)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  in  profiles  1 1  and  12  is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21 ,22,31  and  32  is  prohibited 
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A.6.31  ACTIVITY  INTERRUPT  (Al)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  in  profiles  1 1  and  12  is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21 .22.31  and  32  is  prohibited 

A.6.32  ACTIVITY  INTERRUPT  ACK  (AIA)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  in  profiles  1 1  and  12  is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21 ,22.31  and  32  is  prohibited 

A.6.33  ACTIVITY  DISCARD  (AD)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  in  profiles  1 1  and  12  is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21,22,31  and  32  is  prohibited 

A.6.34  ACTIVITY  DISCARD  ACK  (ADA)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  in  profiles  1 1  and  12  is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21 ,22,31  and  32  is  prohibited 

A.6.35  ACTIVITY  END  (AE)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  in  profiles  1 1  and  12  is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21,22.31  and  32  is  prohibited 

A.6.36  ACTIVITY  END  ACK  (AEA)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  in  profiles  1 1  and  12  is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21,22,31  and  32  is  prohibited 


December  1992  (Stable) 
PDISP  12061-4 
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ANNEX  B:  Presentation  PROTOCOL  PDUs  (Normative) 


B.1.  PRESENTATION  SERVICE  PARAMETERS 

This  subclause  details  TP's  requirements  on  the  presentation  protocol.  The  reader  should 
consult  the  Upper  Layer  agreements  for  a  detailed  discussion  of  these  services.  This  ISP  only 
specifies  PDU  parameters  necessary  for  this  ISP. 

8.1 .2.  CONNECTION  INITIATOR  or  RESPONDER  CAPABILITIES 


Table  1  -  CONNECTION  INITIATOR  OR  RESPONDER  CAPABILITIES 


ISO/IEC  8823-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

ll 

Initiator 

0 

0101 

b  iResponder 

0 

M 

101 .     If  capable  of  initiating  an  association  then  M,  else  I. 


8.1 .3.  PROTOCOL  MECHANISMS 


Table  2  -PROTOCOL  MECHANISMS 


ISO/lEC  8823-2 

PROFILE 

1  ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

ll 

X.410(1984) 

0 

NA 

1 

b 

Normal 

0 

M 
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NOTES 

1 .  Implementations  that  support  X.41 0  mode  shall  respond  to  a  CP  PPDU  proposing  X.41 0- 
1984  mode  with  an  S-U-ABRT;  where  the  user  data  contains  an  Abort  information  data 
element  (defined  in  X.410),  which  contains  an  AbortReason  (type  INTEGER)  of  value  4 
(protocol  error).  Implementations  that  do  not  support  X.41 0-1 984  mode  shall  respond  with 
either  a  Presentation-Provider  at)ort  or  a  Presentation-Provider  Reject. 

B.I  .4.  FUNCTIONAL  UNITS 


Table  3  -  FUNCTIONAL  UNITS 


ISO/IEC  8823-2 

PROFILE  1 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

Kernel 

M 

M 

NOTES  1 

Presentation  Context  Management 

0 

s— 

Presentation  Context  Restoration 

c 

B.1.5.  PRESENTATION  PDU  USAGE  BY  PROFILE 


Table  4  KERNEL  PDU  USAGE  BY  PROFILE 


ITEM# 

PROTOCOL  DATA  UNITS 

iSO/lEC 
8823-2 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

CONNECT 

PRESENTATION  (CP) 

c/c 

C101 
/M 

C101 
M 

C101 
/M 

C101 
/M 

C101 
/M 

C101 
/M 

2 

CONNECT 

PRESENTATION  ACCEPT 
(CPA) 

c/c 

C102 
/C101 

C102 
/C101 

C102 
/C101 

C102 
/C101 

C102 
/C101 

C102 
/C101 

3 

CONNECT 

PRESENTATION  REJECT 
(CPR) 

c/c 

M 

/C101 

M 

/C101 

M 

/C101 

M 

/C101 

M 

/C101 

M 

/C101 

4 

ABNORMAL  RELEASE 
PROVIDER  (ARP) 

M 

M 

M 

M 

M 

M 

M 

5 

ABNORMAL  RELEASE 
USER(ARU) 

M 

M 

M 

M 

M 

M 

M 

6 

PRESENTATION  DATA 
1  (TD) 

M 

M 

M 

M 

M 

M 

M 

102.     If  capable  of  accepting  an  AARQ  APDU  then  M,  else  NA. 
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B.1.6.  PRESENTATION  CONTEXT  MANAGEMENT  PDU  USAGE  BY 
PROFILE 


Table  5  PRESENTATION  CONTEXT  MANAGEMENT  PDU  USAGE  BY  PROFILE 


1TEM# 

PROTOCOL  DATA  UNITS 

ISO/IEC 
8823-2 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

ALTER  CONTEXT  (AC) 

O/M 

* 

2 

ALTER  CONTEXT  ACKNOWLEDGE 
(ACA) 

M 

B.1.7.  OTHER  PRESENTATION  PDU  USAGE  BY  PROFILE 


Table  6  OTHER  PRESENTATION  PDU  USAGE  BY  PROFILE 


ITEM« 

PROTOCOL  DATA  UNITS 

ISO/IEC 
8823-2 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

PRESENTATION  TYPED  DATA 
(TTD) 

M 

M 

M 

M 

M 

2 

EXPEDITED  DATA  (TE) 

O/M 

• 

CAPABILITY  DATA  (TC) 

O/M 

NA 

NA 

NA 

NA 

N 

CAPABILITY  DATA 
ACKNOWLEDGE  (TCC) 

O/M 

NA 

NA 

NA 

NA 

RESYNCHRONIZE  (RS) 

O/M 

• 

M 

M 

• 

M 

M 

RESYNCHRONIZE 
ACKNOWLEDGE  (RSA) 

O/M 

M 

M 

M 

M 

B.I .8.  PRESENTATION  CONTEXT  RESTORATION  FUNCTIONAL  UNIT 


No  additional  PPDUs. 
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B.2.  SUPPORTED  PARAMETERS 

B.2.1.  CONNECT  PRESENTATION  (CP)  PPDU 


Table  7  -  CONNECT  PRESENTATION  (CP)  PPDU 


ISO/IEC  8823-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Callinq  Presentation  Selector 

0/M 

M 

2 

Called  Presentation  Selector 

0/M 

M 

3 

Mode  Selector 

M 

M 

Normal 

4 

Presentation  Context  Definition  List 

0/M 

M 

5 

Default  Context  Name 

0/M 

C103 

6 

Protocol  Version 

0/M 

M 

7 

Presentation  Requirements 

0/M 

1 

8 

User  Session  Requirements 

0/M 

C104 

1 

9 

User  Data 

0/M 

M 

103.     If  the  Expedited  Data  FU  is  supported  then  M,  else  I. 


104.     If  the  Context  Management  FU  is  supported  then  M,  else  I. 
NOTES 

1 .  TP  does  not  use  this  parameter,  however  a  U-ASE  is  not  prohibited  from  using  it,  subject  to 
the  restrictions  imposed  by  TP  on  the  use  of  Session  Functional  Units. 

B.2.2.  CONNECT  PRESENTATION  ACCEPT  (CPA)  PPDU 


Table  8  -  CONNECT  PRESENTATION  ACCEPT  (CPA)  PPDU 


ISO/IEC  8823-2 

PROFILE 

ITEM« 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/LyV  ALLOWED 

NOTES 

1 

Responding  Presentation  Selector 

O/M 

M 

2 

Mode  Selector 

M 

M 

Normal 

3 

Presentation  Context  Definition  Result 
List 

0/M 

M 

4 

Protocol  Version 

0/M 

M 

5 

Presentation  Requirements 

0/M 

1 

6 

User  Session  Requirements 

0/M 

C104 

1 

7 

User  Data 

0/M 

M 

NOTES 


1 .  TP  does  not  use  this  parameter,  however  a  U-ASE  is  not  prohibited  from  using  it,  subject  to 
restrictions  imposed  by  TP  on  the  use  of  Sesison  Functional  Units. 
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B.2.3.  CONNECT  PRESENTATION  REJECT  (CPR)  PPDU 
Table  9  -  CONNECT  PRESENTATION  REJECT  (CPR)  PPDU 


ISO/IEC  8823-2 

PROFILE 

)TEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Responding  Presentation  Selector 

O/M 

M 

2 

Presentation  Context  Definition  Result 
List 

0/M 

M 

3 

Protocol  Version 

O/M 

M 

4 

Default  Context  Result 

O/M 

0105 

5 

Provider  Reason 

O/M 

M 

1 

6 

User  Data 

O/M 

M 

105.     If  capable  of  proposing  Default  Context  then  M,  else  I. 
NOTES 

1 .   For  enhanced  interoperability  it  is  recommended  that  appropriate  provider  reason  values  be 
sent  with  all  CPR  PPDUs. 

B.2.4.  ABNORMAL  RELEASE  USER  (ARU)  PPDU 

Table  10  -  ABNORMAL  RELEASE  USER  (ARU)  PPDU 


ISO/IEC  8823-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Presentation  Context  Identifier  List 

O/M 

M 

2 

User  Data 

O/M 

M 

B.2.5.  ABNORMAL  RELEASE  PROVIDER  (ARP)  PPDU 

Table  11  -  ABNORMAL  RELEASE  PROVIDER  (ARP)  PPDU 


ISO/IEC  8823-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Abort  Reason 

O/M 

M 

1 

2 

Event  Identifier 

O/M 

M 

2  1 

NOTES 

1 .   For  enhanced  interoperability  it  Is  recommended  that  appropriate  provider  reason  values  be 
sent  with  all  ARP  PPDUs. 
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2.  For  enhanced  interoperability  it  is  recommended  that  appropriate  event  identifier  values  be 
sent  with  all  ARP  PPDUs. 

B.2.6.  ALTER  CONTEXT  (AC)  PPDU 

This  PPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP. 
B.2.7.  ALTER  CONTEXT  ACKNOWLEDGE  (ACA)  PPDU 

This  PPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP. 
B.2.8.  PRESENTATION  DATA  (TD)  PPDU 


Table  12  -  PRESENTATION  DATA  (TD)  PPDU 


ISO/IEC  8823-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

User-data 

O/M 

M 

B.2.9.  PRESENTATION  TYPED  DATA  (TTD)  PPDU 

Table  13  -  PRESENTATION  TYPED  DATA  (TTD)  PPDU 

This  PPDU  is  not  applicable  to  profiles  1 1  and  12. 


BASE  STANDARD  ISO  8823 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

User-data 

O/M 

M 

B.2.10.         EXPEDITED  DATA  (TE)  PPDU 


This  PPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP. 
B.2.1 1 .        CAPABILITY  DATA  (TC)  PPDU 

This  PPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP.  It  can  be  used  by 
Profiles  1 1  and  12  However  its  use  by  a  U-ASE  in  profiles  21 ,22,31  and  32  is  prohibited. 

B.2.12.        CAPABILITY  DATA  ACKNOWLEDGE  (TCC)  PPDU 

This  PPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP.  It  can  be  used  by 
Profiles  11  and  12  However  its  use  by  a  U-ASE  in  profiles  21,22,31  and  32  is  prohibited. 
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B.2.13.         RESYNCHRONIZE  (RS)  PPDU 

Table  14-  RESYNCHRONIZE(RS)PPDU 

This  PPDU  is  not  applicable  to  profiles  1 1  and  12. 


BASE  STANDARD  ISO  8823 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Presentation  Context  Identifier  List 

c/c 

C104 

2 

User-data 

0/M 

M 

B.2.14.         RESYNCHRONIZE  ACKNOWLEDGE  (RSA)  PPDU 
Table  15  -  RESYNCHRONIZE  ACKNOWLEDGE  (RSA)  PPDU 

This  PPDU  is  not  applicable  to  profiles  1 1  and  12. 


BASE  STANDARD  ISO  8823 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTE 

1 

Presentation  Context  Identifier  List 

O/M 

C104 

2 

User-data 

O/M 

M 
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B.2.15.        SESSION  SERVICE  PRIMITIVES  NOT  CARRYING 
PRESENTATION  PCI 


Table  16  SESSION  SERVICE  PRIMITIVES  NOT  CARRYING  PRESENTATION  PCI 


ITEM# 

PRIMITIVES 

ISO/IEC 
8823-2 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

S-REL  req/ind 

0 

O/M 

O/M 

O/M 

O/M 

O/M 

O/M 

2 

S-REL  rsp/cnf 

0 

*(M) 
/CI  06 

*(M) 
/C106 

•(M) 
/C106 

*(M) 
/C106 

*(M) 
/C106 

/C106 

3 

S-PT  req/ind 

0 

M 

M 

M 

M 

4 

S-SYNm  req/ind 

0 

M 

M 

M 

M 

5 

S-SYNm  rsp/cnf 

0 

M 

M 

M 

M 

6 

S-SYNM  req/ind 

c 

* 

• 

* 

7 

S-SYNM  rsp/cnf 

O/M 

• 

• 

• 

8 

S-UER  req/ind 

0 

NA 

NA 

NA 

NA 

NA 

NA 

9 

S-ACTS  req/ind 

0 

NA 

NA 

NA 

NA 

10 

S-ACTR  req/ind 

0 

NA 

NA 

NA 

NA 

11 

S-ACTE  req/ind 

0 

NA 

NA 

NA 

NA 

12 

S-ACTE  rsp/cnf 

0 

NA 

NA 

NA 

NA 

106.     If  capable  of  initiating  an  S-REL  req  M  then  else  I. 
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B.3.  SUPPORT  OF  SYNTAXES 

B.3.1.  TRANSFER  SYNTAXES  SUPPORTED 


Tab!e  17  -  TRANSFER  SYNTAXES  SUPPORTED 


1      SUPPORT  1 

1  n 

ITEM# 

TYPE 

DETA8L 

BASE 

P  i 

1 

Object  Identifier 

ioint-iso-cdtt  asn  1(1)  basic-encodinc!(  1 ) 

Im  ~^ 

M  i 

B.3.2.  ABSTRACT  SYNTAXES  SUPPORTED 


Table  18  -  ABSTRACT  SYNTAXES 


1 

1 

SUPPORT 

NOTES  1 

1  iTEM# 

TYPE 

DETAIL 

PROFILE  ID 

BASE 

p 

Object  Identifier 

joint-iso-cdtt  association-control(2)  abslrac!- 
syntax(l)  apdus(O)  versionl(l) 

0 

y 

r 

Object  Identifier 

joint-iso-ccitt  ccr(7)  abstract-syntax(l)  apdus(O) 

11,12 

0 

1 

1 

version2(2) 

21.22.31.32 

0 

M 

p 

Object  Identifier 

joint-iso-ccitt  tp(10)  abstract-syntax(l)  apdus(O) 
versionl(l) 

0 

M 

NOTES 


1 .  This  ISP  specifies  that  a  referencing  specification  shall  not  use  CCR  when  operating  with 
profile  1 1  or  profile  1 2  (in  particular,  refer  to  Parts  5  and  6  clause  7).  However,  when  the 
abstract  syntaxes  are  negotiated  at  the  Presentation  level,  it  is  not  possible  to  identify 
whether  a  protocol  error  shall  be  detected  or  not  (this  can  be  detected  at  the  OSI  TP  level). 
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ANNEX  C:  ACSE  PROTOCOL  PDUs  (Normative) 


This  subclause  details  TP's  use  of  ACSE  services  and  parameters.  The  reader  should  consult  the  upper 
layer  agreements  for  a  detailed  discussion  of  these  services.  This  ISP  only  specifies  PDU  parameters 
necessary  for  this  ISP. 

C.1.    SUPPORTED  FUNCTIONS 


Table  1  -  SUPPORTED  FUNCTIONS 


ISO/IEC  8650-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

TILN  ALLOWED 

NOTES 

1 

Normal  Mode 

O 

M 

2 

X.410-  1984  mode 

o 

NA 

1 

3 

Rules  for  ExtensibllltY 

M 

M 

4 

Supports  Operation  of  Session  Vers.  2 

O 

M 

NOTES 

1 .   Implementations  that  support  X.41 0  mode  shall  respond  to  a  CP  PPDU  proposing  X.41 0-1 984  mode 
with  an  S-U-ABRT;  where  the  user  data  contains  an  Abortlnformation  data  element  (defined  in 
X.410),  which  contains  an  AbortReason  (type  INTEGER)  of  value  4  (protocol  error).  Implementations 
that  do  not  support  X.41 0-1 984  mode  shall  respond  with  either  a  Presentation- Provider  abort  or  a 
Presentation-Provider  Reject. 

C.2.    INITIATOR/RESPONDER  CAPABILITIES 


Table  2  -INITIATOR/RESPONDER  CAPABILITIES 


ISO/IEC  8650-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

ALLOWED 

NOTES 

1 

Association  Initiator 

0 

11,12 

O 

21,22,31,32 

M 

2 

Association  Responder 

o 

11,12 

M 

1 

21,22,31,32 

M 

NOTES 


1 .  An  implementation  shall  be  capable  of  rejecting  an  AARQ  APDU,  acceptance  of  an  AARQ  APDU  is 
optional. 
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C.3.    FUNCTIOMAL  UNITS 


Table  3  -FUNCTIONAL  UNITS 


1 

ISO/lEC  8650-2 

PROFILE  1 

ITEM# 



PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

1 

Kernel 

M 

M 

NOTES  1 

2 

Authentication 

0 

C.4.    ACSE  PDU  USAGE  BY  PROFILE 


Table  4  ACSE  PDU  USAGE  BY  PROFILE 


ITEM# 

Protocol  Data  Units 

ISO/lEC 

8eso-2 

Profiles 

11 

21 

31 

12 

32 

Notes 

1 

A-ASSOCIATE-REOUEST 
(AARQ) 

c/c 

C101/M 

M 

M 

C101/M 

M 

M 

1 

2 

A-ASSOCIATE-RESPONSE 
(AARE) 

c/c 

M/C101 

M 

M 

M/C101 

M 

M 

1 

3 



A-RELEASE-REQUEST 
(RLRQ) 

O/M 

O/M 

O/M 

O/M 

O/M 

O/M 

O/M 

4 

A-RELEASE-RESPONSE 
(RLRE) 

M/C 

M/C102 

M/C102 

M/C102 

M/C102 

M/C102 

M/C102 

5 

A-ABORT  (ABRT) 

C/C 

M 

M 

M 

M 

M 

M 

101 .     If  capable  of  initiating  an  Association  then  M,  else  I. 


102.     If  capable  of  initiating  A-RELEASE  then  M,  else  I. 
NOTES 

1 .  All  implementations,  including  initiator  only  ones,  shall  have  the  capability  to  receive  an  AARQ  APOU 
and  rejecting  it  with  an  AARE  APDU. 
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C.5.    A-ASSOCIATE-REQUEST  (AARQ) 

Table  5  -  A-ASSOCIATE-REQUEST  (AARQ) 


ISO/IEC  8650-2 

PROFILE 

— 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

r^lUlOCUl  VofSIOn 

V_//  IVI 

M 

IVI 

2 

Application  Context  Name 

M 

M 

3 

Calling  AP  Title 

0/M 

11,12 

0/M 

See  Table  10 

1 

21,31.22,32 

M 

See  Table  1 0 

4 

Calllno  AE  Qualifier 

0/1^ 

11,12 

0/M 

see  laoie  luoee  laoie 
10 

1  1 

 ! 

91  "W  ">">  ^9 

M 

IVl 

1 

5 

oaiiing  An  invocauon  luenunei 

n/M 

<Jl  IVI 

1119 

\jlvn 

4 

1 

21,31,22,32 

0/M 

1,2 

c 
o 

Calling  AE  Invocation  Identifier 

0/M 

1 1,12 

0/M 

1 

91  "Jl  99  "V) 

n/M 

1  9 

1 

Called  AP  Title 

0/M 

O/M 

See  Table  10 

8 

Called  AE  Qualifier 

0/M 

0/M 

See  Table  10 

9 

Called  AP  Invocation  Identifier 

0/M 

11.12 

0/M 

1.3 

21,31.22,32 

0/M 

1,3 

10 

Called  AE  Invocation  Identifier 

0/M 

11.12 

O/MO/M 

1,3 

21.31,22,32 

1,3 

11 

Implementattion  Information 

C/M 

12 

Requester  ACSE  Requirements 

C/M 

13 

Mechanism  Name 

C/M 

Callinq  Authentication  Value 

C/M 

• 

ii— 

User  Information 

0/M 

M 

NOTES 


1 .  For  implementations  using  association  pools,  these  parameters  are  recommended  in  order  to  re-use 
associations. 

2.  If  this  parameter  is  received,  then  it  is  recommended  to  be  logged  and  used  for  the  reestablishment 
of  the  association  during  transaction  recovery. 

3.  If  this  parameter  is  sent,  then  it  is  recommended  to  be  logged  and  used  for  the  reestablishment  of  the 
association  during  transaction  recovery. 
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C.6.    A-ASSOCIATE-RESPONSE  (AARE) 


Table  6  -  A-ASSOCIATE-RESPONSE  (AARE) 


ISO/IEC  8650-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

1I\JM  ALLOWED 

NOTES 

1 

1 

rroiocoi  version 

M 

2 

Applicstion  ContGxt  Nams 

IVi 

M 
M 

3 

Rssponding  AP  Title 

U/M 

11  1  o 

1 1 ,1  c 

oee  1  aoie  i  u 

1 

21,31,22,32 

M 

See  Table  10 

1 

Responding  AE  Qualifier 

0/M 

1 1,12 

0/M 

See  Table  10 

1 

M 

See  Table  1 0 

1 

5 

Responding  AP  Invocation  Identifier 

0/M 

11,12 

0/M 

21,31,22,32 

0/M 

2 

6 

Responding  AE  Invocation  Identifier 

0/M 

11,12 

0/M 

21,31,22,32 

0/M 

2 

7 

Result 

M 

M 

8 

Result  Source  -  Diagnostic 

M 

M 

1-10 

0 

11  - 14 

9 

Implementation  Information 

0/M 

1 

10 

Requester  ACSE  Requirements 

C/M 

11 

Mechanism  Name 

C/M 

12 

Galling  Authentication  Value 

C/M 

13 

User  Information 

0/M 

M 

NOTES 


1 .  Tliis  parameter  shall  be  present  on  an  AARE  APDU  if  the  called  parameter  was  present  in  the  AARQ 
APDU  and  the  responding  parameter  is  different  from  the  called  parameter. 

2.  If  this  parameter  is  received,  then  it  is  recommended  to  be  logged  and  used  for  re-establishment  of 
the  association  during  transaction  recovery. 


C.7     A-RELEASE-REQUEST  (RLRQ) 

Table  7  -  A-RELEASE-REQUEST  (RLRQ) 


ISO/IEC  8650-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

ALLOWED 

NOTES 

1 

Reason 

0/M 

2 

User  information 

O/M 

1 
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C.8.    A-RELEASE-RESPONSE  (RLRE) 

Table  8  -  A-RELEASE-RESPONSE  (RLRE) 


ISO/IEC  8650-2 

PROFILE 

ITEIM 

PARAMETER 

STATUS 

PROFILE  ID  STATUS 

T/L/V  ALLOWED 

NOTES 

Reason 

0/M 

i 

User  information 

0/M 

C.9.    A-ABORT  (ABRT) 

Table  9  -  A-ABORT  (ABRT) 


ISO/IEC  86S0-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES  1 

1 

Abort  Source 

M 

M 

2 

Abort  Diaqnostic 

0 

3 

User  Information 

0/M 

M 

CIO.  AE  TITLE  NAME  FORMS 


Table  10  -  AE  TITLE  UAME  FORMS 


1 

ISO/IEC  8650-2 

PROFILE 

ITEM# 

SYNTAX  FORM 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Form  1  (Directory  Name) 

0/M 

0/M 

1  ..  1024  octets 

1 

2 

Form  2  (Object  ID) 

0/M 

M 

1  ..  64  octets 

1 

NOTES 

1 .  The  limits  specified  apply  to  the  AE-Title  which  is  the  combination  of  the  AP-Title  and  AE-Qualifier. 
They  are  specified  in  line  with  the  limits  given  in  Part  3  on  the  Atomic-Action  Identifier  and  the  Branch 
Identifier. 
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C.11.  AUTHENTICATION  VALUE  FORM 


Table  11  -  AUTHENTICATION  VALUE  FORM 


iSO/lEC  8650-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

VUW  ALLOWED 

NOTES 

Graphic  String 

0/C 

Bit  String 

c/c 

• 

External 

c/c 

Any  Defined  By 

c/c 
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Introduction 

The  aim  of  Open  Systems  Interconnection  is  to  allow,  with  a  minimum  of  technical  agreement  outside  the 
interconnection  standards,  the  interconnection  of  computer  systems 

a.  from  different  manufacturers, 

b.  under  different  management, 

c.  of  different  levels  of  complexity, 

d.  of  different  technologies. 

Transaction  Processing  is  concemed  with  identifiable  information  which  can  be  related  as  transactions, 
which  may  involve  two  or  more  Open  Systems.  In  the  framework  of  Open  Systems  Interconnection  (OSI) 
a  transaction  is  defined  as  "a  set  of  related  operations  characterized  by  four  properties:  atomicity, 
consistency,  isolation  and  durability." 

The  definition  highlights  that  a  distributed  transaction  is  more  than  a  simple  exchange  of  messages,  but 
that  the  exchanges  form  a  protected  indivisible  set. 


This  multi-part  document  contains  the  complete  specification  of  the  six  profiles  identified  in  M-IT-02  and 
TR  10000. 

Part  1  contains  the  taxonomy  for  the  OSI  TP  profiles. 

Part  2  contains  the  specification  of  the  support  of  OSI  TP  APDUs  for  each  of  the  profiles  specified  in 
Parts  5  to  10. 

Part  3  contains  the  specification  of  the  support  of  the  CCR  APDUs  for  each  of  the  profiles  specified  in 
Part  5  to  10. 

Part  4  contains  the  specification  of  the  support  of  ACSE,  Presentation  and  Session  APDUs  for  each  of 
the  profiles  specified  in  Part  5  to  10. 

Parts  5  to  10  specify  the  six  profiles  which  are  defined,  based  on  the  OSI  TP  standard.  These  six  parts 
make  reference  to  Parts  2  to  4. 
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Information  Technology  -  Open  Systems  Interconnection  -  International 
Standardized  Profiles  12061-5:  OSI  Distributed  Transaction  Processing. 

Part  5:  APPLICATION  SUPPORTED  TRANSACTIONS  -  POLARIZED  CONTROL 
(ATP11) 

1.  SCOPE 

This  Part  of  this  ISP  defines  the  OSI  TP  profile  used  for  Application  Supported  Transaction  while  the 
application  is  using  the  Polarized  Control  paradigm  for  communications. 

2.  NORMATIVE  REFERENCES 

The  references  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

3.  DEFINITIONS  AND  ABBREVIATIONS 

The  definitions  and  abbreviations  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

4.  OVERVIEW 

Profile  ATP1 1  is  applicable  to  end  systems  concerned  with  operating  in  the  Open  Systems 
Interconnection  (OSI)  environment.  This  profile  specifies  a  combination  of  OSI  standards,  which 
collectively  provide  support  for  Application  Supported  Distributed  Transactions,  where  the  applications 
take  responsibility  for  ensuring  that  transaction  semantics  are  maintained,  and  for  restoring  consistency 
after  any  failure.  The  dialogue  between  the  applications  is  subject  to  strict  turn  control.  The  handshake 
facility  is  available. 

5.  USE  OF  FUNCTIONAL  UNITS 

An  implementation  of  this  profile  supports  the  OSI  TP  functional  units  identified  in  the  table  hereafter: 


DIALOGUE 

POLARIZED  CONTROL 
HANDSHAKE 


mandatory 
mandatory 
mandatory 


It  conforms  to  the  Application  Transactions  conformance  class  defined  in  ISO  1 0026-3. 
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6.  SCENARIO 

The  applicability  of  the  ATP1 1  profile  is  illustrated  by  the  figure  hereafter: 


TP  SYSTEM 

TP  SYSTEM 

ATP11 

7.       USAGE  OF  UNDERLYING  STANDARDS 

This  profile  specifies  the  required  functions  from  the  supporting  protocol  stacks  shown  below.  The  use  of 
ISO/I  EC  9804/9805  (CCR)  by  a  referencing  specification  is  forbidden  and  is  a  protocol  error. 


Application  Layer 

ISO  10026-3:1992  (OSI  TP) 
ISO  8650  1  (ACSE) 

Presentation  Layer 

ISO  8825:1990  (BER  ASN.1) 
ISO  8823:1 988(Presentation) 

— — —  

Session  Layer 

ISO  83273 

8.  DETAILED  DESCRIPTION 

The  support  of  the  OSI  TP,  ACSE,  Presentation  and  Session  PDUs  for  ATP1 1  is  as  described  in  Parts 
1 .2  and  4  of  this  standard. 

9.  CONFORMANCE 

Conformance  requirements  specified  in  ISO/IEC  ISP  12061-1,  ISO/IEC  ISP  12061-2,  ISO/IEC  ISP 
12061-4  apply  to  this  part. 

For  each  implementation  claiming  conformance  to  this  part  of  ISO/IEC  12061,  the  following  PICS 
Proformas  shall  be  completed  and  made  available  : 

•  ISO/IEC  10026-4  (OSI  TP) 

•  ISO/IEC  8650-2  (ACSE) 

•  ISO/IEC  8823-2  (Presentation) 


^To  be  published 
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INTRODUCTION 

The  aim  of  Open  Systems  Interconnection  is  to  allow,  with  a  minimum  of  technical  agreement  outside  the 
interconnection  standards,  the  interconnection  of  computer  systems 

a.  from  different  manufacturers, 

b.  under  different  management, 

c.  of  different  levels  of  complexity, 

d.  of  different  technologies. 

Transaction  Processing  is  concerned  with  identifiable  information  which  can  be  related  as  transactions, 
which  may  involve  two  or  more  Open  Systems.  In  the  framework  of  Open  Systems  Interconnection  (OSI) 
a  transaction  is  defined  as  "a  set  of  related  operations  characterized  by  four  properties:  atomicity, 
consistency,  isolation  and  durability." 

The  definition  highlights  that  a  distributed  transaction  is  more  than  a  simple  exchange  of  messages,  but 
that  the  exchanges  fomi  a  protected  indivisible  set. 


This  multi-part  document  contains  the  complete  specification  of  the  six  profiles  identified  in  M-IT-02  and 
TR  10000. 

Part  1  contains  the  taxonomy  for  the  OSI  TP  profiles. 

Part  2  contains  the  specification  of  the  support  of  OSI  TP  APDUs  for  each  of  the  profiles  specified  in 
Parts  5  to  10. 

Part  3  contains  the  specification  of  the  support  of  the  OCR  APDUs  for  each  of  the  profiles  specified  in 
Part  5  to  10. 

Part  4  contains  the  specification  of  the  support  of  ACSE,  Presentation  and  Session  APDUs  for  each  of 
the  profiles  specified  in  Part  5  to  10. 

Parts  5  to  10  specify  the  six  profiles  which  are  defined,  based  on  the  OSI  TP  standard.  These  six  parts 
make  reference  to  Parts  2  to  4. 
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Information  Technology  -  Open  Systems  Interconnection  -  International 
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Part  6:  APPLICATION  SUPPORTED  TRANSACTIONS  -  SHARED  CONTROL 
(ATP12) 

1.  SCOPE 

This  Part  of  this  ISP  defines  the  OSI  TP  profile  used  for  Application  Supported  Transaction  while  the 
application  is  using  the  Shared  Control  paradigm  for  communications. 

2.  NORMATIVE  REFERENCES 

The  references  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

3.  DEFINITIONS  AND  ABBREVIATIONS 

The  definitions  and  abbreviations  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

4.  OVERVIEW 

Profile  ATP12  is  applicable  to  end  systems  concerned  with  operating  in  the  Open  Systems 
Interconnection  (OSI)  environment.  This  profile  specifies  a  combination  of  OSI  standards,  which 
collectively  provide  support  for  Application  Supported  Distributed  Transactions,  where  the  applications 
take  responsibility  for  ensuring  that  transaction  semantics  are  maintained,  and  for  restoring  consistency 
after  any  failure.  The  dialogue  between  the  applications  is  not  subject  to  turn  control.  The  support  of  the 
handshake  facility  is  optional. 


5. 


USE  OF  FUNCTIONAL  UNITS 


An  implementation  of  this  profile  supports  the  OSI  TP  functional  units  as  shown  hereafter: 


DIALOGUE 
SHARED  CONTROL 
HANDSHAKE 


mandatory 
mandatory 
optional 


It  conforms  to  the  Application  Transactions  conformance  class  defined  in  ISO  10026-3. 
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6.  SCENARIO 

The  applicability  of  the  ATP12  profile  is  illustrated  by  the  figure  hereafter: 


TP  SYSTEM 

TP  SYSTEM 

ATP12 

7.       USAGE  OF  UNDERLYING  STANDARDS 

This  profile  specifies  the  required  functions  from  the  suppxjrting  protocol  stacks  shown  below.  The  use  of 
ISO/I  EC  9804/9805  (CCR)  by  a  referencing  specification  is  forbidden  and  is  a  protocol  error. 


Application  Layer 

ISO  10026-3:1992  (OSI  TP) 
ISO  8650  ^  (ACSE) 

Presentation  Layer 

ISO  8825:1990  (BER  ASN.1) 
ISO  8823:1 988(Presentation) 

Session  Layer 

ISO  8327'* 

8.  DETAILED  DESCRIPTION 

The  support  of  the  OSI  TP,  ACSE,  Presentation  and  Session  PDUs  for  ATP1 2  is  as  described  in  Parts 
1 ,2  and  4  of  this  standard. 

9.  CONFORMANCE  f  r 

Conformance  requirements  specified  in  ISO/I  EC  ISP  12061-1,  ISO/IEC  ISP  12061-2,  ISO/IEC  ISP 
12061-4  apply  to  this  part. 

For  each  implementation  claiming  conformance  to  this  part  of  ISO/IEC  12061 ,  the  following  PICS 
Proformas  shall  be  completed  and  made  available  : 
•       ISO/IEC  10026-4  (OSI  TP) 


*To  be  published 
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ISO/IEC  8650-2  (ACSE) 
ISO/IEC  8823-2  (Presentation) 
ISO/IEC  8327-2  (Session) 
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INTRODUCTION 

The  aim  of  Open  Systems  Interconnection  is  to  allow,  with  a  minimum  of  technical  agreement  outside  the 
interconnection  standards,  the  interconnection  of  computer  systems 

a.  from  different  manufacturers, 

b.  under  different  management, 

c.  of  different  levels  of  complexity, 

d.  of  different  technologies. 

Transaction  Processing  is  concemed  with  identifiable  information  which  can  be  related  as  transactions, 
which  may  involve  two  or  more  Open  Systems.  In  the  framework  of  Open  Systems  Interconnection  (OSI) 
a  transaction  is  defined  as  "a  set  of  related  operations  characterized  by  four  properties:  atomicity, 
consistency,  isolation  and  durability." 

The  definition  highlights  that  a  distributed  transaction  is  more  than  a  simple  exchange  of  messages,  but 
that  the  exchanges  fomn  a  protected  indivisible  set. 


This  multi-part  document  contains  the  complete  specification  of  the  six  profiles  identified  in  M-IT-02  and 
TR  10000. 

Part  1  contains  the  taxonomy  for  the  OSI  TP  profiles. 

Part  2  contains  the  specification  of  the  support  of  OSI  TP  APDUs  for  each  of  the  profiles  specified  in 
Parts  5  to  10. 

Part  3  contains  the  specification  of  the  support  of  the  CCR  APDUs  for  each  of  the  profiles  specified  in 
Part  5  to  10. 

Part  4  contains  the  specification  of  the  support  of  ACSE,  Presentation  and  Session  APDUs  for  each  of 
the  profiles  specified  in  Part  5  to  10. 

Parts  5  to  10  specify  the  six  profiles  which  are  defined,  based  on  the  OSI  TP  standard.  These  six  parts 
make  reference  to  Parts  2  to  4. 
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Information  Technology  -  Open  Systems  Interconnection  -  International 
Standardized  Profiles  12061-7:  OSI  Distributed  TRANSACTION  PROCESSING. 


Part  7:  PROVIDER  SUPPORTED  UNCHAINED  TRANSACTIONS  -  POLARIZED 
CONTROL  (ATP21) 

1.  SCOPE 

This  Part  of  this  ISP  defines  the  OSI  TP  profile  used  for  unchained  sequences  of  Provider  Supported 
Transaction  branches  while  the  application  is  using  the  Polarized  Control  paradigm  for  comnrujnications. 

2.  NORMATIVE  REFERENCES 

The  references  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

3.  DEFINITIONS  AND  ABBREVIATIONS 

The  definitions  and  abbreviations  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

4.  OVERVIEW 

Profile  ATP21  is  applicable  to  end  systems  concerned  with  operating  in  the  Open  Systems 
Interconnection  (OSI)  environment.  This  profile  specifies  a  combination  of  OSI  standards,  which 
collectively  provide  support  for  Provider  Supported  Distributed  Transactions,  where  the  provider  of  the 
OSI  TP  sen^ice  takes  responsibility  for  ensuring  transaction  ACID  properties  and  for  restoring  consistency 
after  any  failure.  Two  applications  operate  on  a  dialogue  in  an  Unchained  sequence  of  Provider 
Supported  Transaction  Branches.  The  dialogue  between  the  applications  is  subject  to  strict  turn  control. 
The  handshake  facility  is  available. 

5.  USE  OF  FUNCTIONAL  UNITS 

An  implementation  of  this  profile  supports  the  OSI  TP  functional  units  as  shown  hereafter: 


It  conforms  to  the  Unchained  Provider  Supported  Transaction  Branches  conformance  class  defined  in 
ISO  10026-3. 


DIALOGUE 

POLARIZED  CONTROL 

HANDSHAKE 

COMMIT 

UNCHAINED  TRANSACTIONS 
RECOVERY 


mandatory 
mandatory 
mandatory 
mandatory 
mandatory 
mandatory 
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6.  SCENARIO 

The  applicability  of  the  ATP21  profile  is  illustrated  by  the  figure  hereafter: 


TP  SYSTEM 

TP  SYSTEM 

ATP21 

7.       USAGE  OF  UNDERLYING  STANDARDS 

This  profile  specifies  the  required  functions  from  the  supporting  protocol  stacks  shown  below. 


Application  Layer 

ISO  10026-3:1992  (OSI  TP) 
ISO  8650  1  (ACSE) 
ISO  9805:1 990(CCR) 
ISO  9805  AM 2 

Presentation  Layer 

ISO  8825:1990  (BER  ASN.1) 
ISO  8823:1 988(Presentation) 
ISO  8823  AM  5 

Session  Layer 

ISO  83275 
ISO  8327  AM3 

8.       DETAILED  DESCRIPTION 

The  support  of  the  OSI  TP,  CCR,  ACSE,  Presentation  and  Session  PDUs  for  ATP21  is  as  described  in 
Parts  1  -  4  of  this  standard. 

<  9.  CONFORMANCE 

Conformance  requirements  specified  in  ISO/I  EC  ISP  12061-1,  ISO/IEC  ISP  12061-2,  ISO/IEC  ISP 
1 2061  -3,  ISO/IEC  ISP  1 2061  -4  apply  to  this  part. 

For  each  implementation  claiming  conformance  to  this  part  of  ISO/IEC  12061,  the  following  PICS 
Proformas  shall  be  completed  and  made  available  : 

ISO/IEC  10026-4  (OSI  TP) 

ISO/IEC  9805-2  (CCR) 
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INTRODUCTION 

The  aim  of  Open  Systems  Interconnection  is  to  allow,  with  a  minimum  of  technical  agreement  outside  the 
interconnection  standards,  the  interconnection  of  computer  systems 

a.  from  different  manufacturers, 

b.  under  different  management, 

c.  of  different  levels  of  complexity, 

d.  of  different  technologies. 

Transaction  Processing  is  concerned  with  identifiable  information  which  can  be  related  as  transactions, 
which  may  involve  two  or  more  Open  Systems.  In  the  framework  of  Open  Systems  Interconnection  (OSI) 
a  transaction  is  defined  as  "a  set  of  related  operations  characterized  by  four  properties:  atomicity, 
consistency,  isolation  and  durability." 

The  definition  highlights  that  a  distributed  transaction  is  more  than  a  simple  exchange  of  messages,  but 
that  the  exchanges  form  a  protected  indivisible  set. 


This  multi-part  document  contains  the  complete  specification  of  the  six  profiles  identified  in  M-IT-02  and 
TR  10000. 

Part  1  contains  the  taxonomy  for  the  OSI  TP  profiles. 

Part  2  contains  the  specification  of  the  support  of  OSI  TP  APDUs  for  each  of  the  profiles  specified  in 
Parts  5  to  10. 

Part  3  contains  the  specification  of  the  support  of  the  OCR  APDUs  for  each  of  the  profiles  specified  in 
Part  5  to  10. 

Part  4  contains  the  specification  of  the  support  of  ACSE,  Presentation  and  Session  APDUs  for  each  of 
the  profiles  specified  in  Part  5  to  10. 

Parts  5  to  10  specify  the  six  profiles  which  are  defined,  based  on  the  OSI  TP  standard.  These  six  parts 
make  reference  to  Parts  2  to  4. 
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information  Technology  -  Open  Systems  Interconnection  -  International 
Standardized  Profiles  12061-8:  OSI  Distributed  Transaction  Processing. 


Part  8:  PROVIDER  SUPPORTED  UNCHAINED  TRANSACTIONS  -  SHARED 
CONTROL  (ATP22) 

1.  SCOPE 

This  Part  of  this  ISP  defines  the  OSI  TP  profile  used  for  Unchained  sequences  of  Provider  Supported 
Transaction  branches  while  the  application  is  using  the  Shared  Control  paradigm  for  communications. 

2.  NORMATIVE  REFERENCES 

The  references  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

3.  DEFINITIONS  AND  ABBREVIATIONS 

The  definitions  and  abbreviations  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

4.  OVERVIEW 

Profile  ATP22  is  applicable  to  end  systems  concerned  with  operating  in  the  Open  Systems 
Interconnection  (OSI)  environment.  This  profile  specifies  a  combination  of  OSI  starKiards,  which 
collectively  provide  support  for  Provider  Supported  Distributed  Transactions,  where  the  provider  of  the 
OSI  TP  sen/ice  takes  responsibility  for  ensuring  transaction  ACID  properties  and  for  restoring  consistency 
after  any  failure.  Two  applications  operate  on  a  dialogue  in  an  Unchained  sequence  of  Provider 
Supported  Transaction  Branches.  The  dialogue  between  the  applications  is  not  subject  to  turn  control. 
The  support  of  the  handshake  facility  is  optional. 

5.  USE  OF  FUNCTIONAL  UNITS 

An  implementation  of  this  profile  supports  the  OSI  TP  functional  units  as  shown  hereafter: 


It  conforms  to  the  Unchained  Provider  Supported  Transactions  Branches  conformance  class  defined  in 
ISO  10026-3. 


DIALOGUE 
SHARED  CONTROL 
HANDSHAKE 
COMMIT 

UNCHAINED  TRANSACTION 
RECOVERY 


mandatory 
mandatory 
mandatory 


mandatory 
mandatory 
optional 
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6.  SCENARIO 

The  applicability  of  the  ATP22  profile  is  illustrated  by  the  figure  hereafter: 


TP  SYSTEM 

TP  SYSTEM 

ATP22 

7.       USAGE  OF  UNDERLYING  STANDARDS 

This  profile  specifies  the  required  functions  from  the  supporting  protocol  stacks  shown  below. 


Application  Layer 

ISO  10026-3:1992  (OSI  TP) 
ISO  8650  (ACSE) 
ISO9805:1990(CCR) 
ISO  9805  AM2 

Presentation  Layer 

ISO  8825:1990  (BER  ASN.1) 
ISO  8823:1 988(Presentation) 
ISO  8823  AM  5 

Session  Layer 

ISO  83276 
ISO  8327  AM3 

8.  DETAILED  DESCRIPTION 

The  support  of  the  OSI  TP,  CCR,  ACSE,  Presentation  and  Session  PDUs  for  ATP2^is  as  described  in 
Parts  1  -  4  of  this  standard. 

9.  CONFORMANCE  ' 


Conformance  requirements  specified  in  ISO/lEC  ISP  12061-1.  ISO/IEC  ISP  12061-2,  ISO/IEC  ISO/IEC 
ISP  12061-3.  ISP  12061-4  apply  to  this  part. 

For  each  implementation  claiming  conformance  to  this  part  of  ISO/IEC  1 2061 ,  the  following  PICS 
Proformas  shall  be  completed  and  made  available  : 

•  ISO/IEC  10026-4  (OSI  TP) 
ISO/IEC  9805-2  (CCR) 

•  ISO/IEC  8650-2  (ACSE) 
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INTRODUCTION 

The  aim  of  Open  Systems  Interconnection  is  to  allow,  with  a  minimum  of  technical  agreement  outside  the 
interconnection  standards,  the  interconnection  of  computer  systems 

a.  from  different  manufacturers, 

b.  under  different  management, 

c.  of  different  levels  of  complexity, 

d.  of  different  technologies. 

Transaction  Processing  is  concerned  with  identifiable  information  which  can  be  related  as  transactions, 
which  nray  involve  two  or  more  Open  Systems.  In  the  framework  of  Open  Systems  Interconnection  (OSI) 
a  transaction  Is  defined  as  "a  set  of  related  operations  characterized  by  four  properties:  atomicity, 
consistency,  isolation  and  durability." 

The  definition  highlights  that  a  distributed  transaction  is  more  than  a  simple  exchange  of  messages,  but 
that  the  exchanges  form  a  protected  indivisible  set. 


This  multi-part  document  contains  the  complete  specification  of  the  six  profiles  identified  in  M-IT-02  and 
TR  10000. 

Part  1  contains  the  taxonomy  for  the  OSI  TP  profiles. 

Part  2  contains  the  specification  of  the  support  of  OSI  TP  APDUs  for  each  of  the  profiles  specified  in 
Parts  5  to  10. 

Part  3  contains  the  specification  of  the  support  of  the  OCR  APDUs  for  each  of  the  profiles  specified  in 
Part  5  to  10. 

Part  4  contains  the  specification  of  the  support  of  ACSE,  Presentation  and  Session  APDUs  for  each  of 
the  profiles  specified  in  Part  5  to  10. 

Parts  5  to  10  specify  the  six  profiles  which  are  defined,  based  on  the  OSI  TP  standard.  These  six  parts 
make  reference  to  Parts  2  to  4. 
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Information  Technology  •  Open  Systems  Interconnection  -  International 
Standardized  Profiles  12061-9:  OSI  Distributed  Transaction  Processing. 


Part  9:  PROVIDER  SUPPORTED  CHAINED  TRANSACTIONS  -  POLARIZED 
CONTROL  (ATP31) 

1.  SCOPE 

This  Part  of  this  ISP  defines  the  OSI  TP  profile  used  for  chained  sequences  of  Provider  Supported 
Transaction  branches  while  the  application  is  using  the  Polarized  Control  paradigm  for  communications. 

2.  NORMATIVE  REFERENCES 

The  references  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

3.  DEFINITIONS  AND  ABBREVIATIONS 

The  definitions  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

4.  OVERVIEW 

Profile  ATP31  is  applicable  to  end  systems  concerned  with  operating  in  the  Open  Systems 
Interconnection  (OSI)  environment.  This  profile  specifies  a  combination  of  OSI  standards,  which 
collectively  provide  support  for  Provider  Supported  Distributed  Transactions,  where  the  provider  of  the 
OSI  TP  sen/ice  takes  responsibility  for  ensuring  transaction  ACID  properties  and  for  restoring  consistency 
after  any  failure.  Two  applications  operate  on  a  dialogue  in  an  Chained  Sequence  of  Provider  Supported 
Transaction  Branches.  The  dialogue  between  the  applications  is  subject  to  strict  tum  control.  The 
handshake  facility  is  available. 

5.  USE  OF  FUNCTIONAL  UNITS 

An  implementation  of  this  profile  supports  the  OSI  TP  functional  units  as  shown  hereafter: 


DIALOGUE 

mandatory 

POLARIZED  CONTROL 

mandatory 

HANDSHAKE 

mandatory 

COMMIT 

mandatory 

CHAINED  TRANSACTION 

mandatory 

RECOVERY 

mandatory 

It  conforms  to  the  Chained  Provider  Supported  Transaction  Branches  conformance  class  defined  in 
ISO  10026-3. 
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6.  SCENARIO 

The  applicability  of  the  ATP31  profile  is  illustrated  by  the  figure  hereafter: 


TP  SYSTEM 

TP  SYSTEM 

ATP31 

7.       USAGE  OF  UNDERLYING  STANDARDS 

This  profile  specifies  the  required  functions  from  the  supporting  protocol  stacks  shown  below. 


Application  Layer 

ISO  10026-3:1992  (OSI  TP) 
ISO  8650  (ACSE) 
ISO9805:1990(CCR) 
ISO  9805  AM2 

Presentation  Layer 

ISO  8825:1990  (BER  ASN.1) 
ISO  8823:1 988(Presentation) 
ISO  8823  AM 5 

Session  Layer 

ISO  83277 
ISO  8327  AM3 

8.  DETAILED  DESCRIPTION 

The  support  of  the  OSI  TP,  CCR,  ACSE,  Presentation  and  Session  PDUs  for  ATP31  is  as  described  in 
Parts  1  -4  of  this  standard. 

9.  CONFORMANCE 

Conformance  requirements  specified  in  ISO/I  EC  ISP  12061-1,  ISO/IEC  ISP  12061-2,  ISO/I  EC  ISO/IEC 
ISP  12061-3,  ISP  12061-4  apply  to  this  part. 

For  each  implementation  claiming  conformance  to  this  part  of  ISO/IEC  12061,  the  following  PICS 
Proformas  shall  be  completed  and  made  available  : 

•  ISO/IEC  10026-4  (OSI  TP) 

•  ISO/IEC  9805-2  (CCR) 

•  ISO/IEC  8650-2  (ACSE) 
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INTRODUCTION 

The  aim  of  Open  Systems  Interconnection  is  to  allow,  with  a  minimum  of  technical  agreement  outside  the 
interconnection  standards,  the  interconnection  of  computer  systems 

a.  from  different  manufacturers, 

b.  under  different  management, 

c.  of  different  levels  of  complexity, 

d.  of  different  technologies. 

Transaction  Processing  is  concerned  with  identifiable  information  which  can  be  related  as  transactions, 
which  may  involve  two  or  more  Open  Systems.  In  the  framework  of  Open  Systems  Interconnection  (OSI) 
a  transaction  is  defined  as  "a  set  of  related  operations  characterized  by  four  properties:  atomicity, 
consistency,  isolation  and  durability." 

The  definition  highlights  that  a  distributed  transaction  is  more  than  a  simple  exchange  of  messages,  but 
that  the  exchanges  form  a  protected  indivisible  set. 


This  multi-part  document  contains  the  complete  specification  of  the  six  profiles  identified  in  M-IT-02  and 
TR  10000. 

Part  1  contains  the  taxonomy  for  the  OSI  TP  profiles. 

Part  2  contains  the  specification  of  the  support  of  OSI  TP  APDUs  for  each  of  the  profiles  specified  in 
Parts  5  to  10. 

Part  3  contains  the  specification  of  the  support  of  the  CCR  APDUs  for  each  of  the  profiles  specified  in 
Part  5  to  10. 

Part  4  contains  the  specification  of  the  support  of  ACSE,  Presentation  and  Session  APDUs  for  each  of 
the  profiles  specified  in  Part  5  to  10. 

Parts  5  to  10  specify  the  six  profiles  which  are  defined,  based  on  the  OSI  TP  standard.  These  six  parts 
make  reference  to  Parts  2  to  4. 
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Information  Technology  -  Open  Systems  Interconnection  -  International 
Standardized  Profiles  12061-10:  OSI  Distributed  Transaction  Processing. 


Part  10:  PROVIDER  SUPPORTED  CHAINED  TRANSACTIONS  ■  SHARED 
CONTROL  (ATP32) 


1.  SCOPE 

This  Part  of  this  ISP  defines  the  OSI  TP  profile  used  for  chained  sequences  of  Provider 
Supported  Transaction  branches  while  the  application  is  using  the  Shared  Control  paradigm  for 
communications. 

2.  NORMATIVE  REFERENCES 

The  references  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

3.  DEFINITIONS  AND  ABBREVIATIONS 

The  definitions  and  abbreviations  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

4.  OVERVIEW 

Profile  ATP32  is  applicable  to  end  systems  concerned  with  operating  in  the  Open  Systems 
Interconnection  (OSI)  environment.  This  profile  specifies  a  combination  of  OSI  staridards,  which 
collectively  provide  support  for  Provider  Supported  Distributed  Transactions,  where  the  provider 
of  the  OSI  TP  service  takes  responsibility  for  ensuring  transaction  ACID  properties  and  for 
restoring  consistency  after  any  failure.  Two  applications  operate  on  a  dialogue  in  an  Chained 
sequence  of  Provider  Supported  Transaction  Branches.  The  dialogue  between  the  applications 
is  not  subject  to  turn  control.  The  support  of  the  handshake  facility  is  optional. 

5.  USE  OF  FUNCTIONAL  UNITS 

An  implementation  of  this  profile  supports  the  OSI  TP  functional  units  as  shown  hereafter: 


It  conforms  to  the  Chained  Provider  Supported  Transaction  Branches  conformance  class  defined 
in  ISO  10026-3. 


DIALOGUE 
SHARED  CONTROL 
HANDSHAKE 
COMMIT 

CHAINED  TRANSACTION 
RECOVERY 


mandatory 
mandatory 
mandatory 


mandatory 
mandatory 
optional 
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6.  SCENARIO 


The  applicability  of  the  ATP32  profile  is  illustrated  by  the  figure  hereafter: 


TP  SYSTEM 

TP  SYSTEM 

ATP32 

7.       USAGE  OF  UNDERLYING  STANDARDS 

This  profile  specifies  the  required  functions  from  the  supporting  protocol  stacks  shown  below. 


Application  Layer 

ISO  10026-3:1992  (OSI  TP) 
ISO  8650  1  (ACSE) 
ISO  9805:1 990(CCR) 
ISO  9805  AM2 

Presentation  Layer 

ISO  8825:1990  (BER  ASN.1) 
ISO  8823:1988(Presentation) 
ISO  8823  AM  5 

Session  Layer 

ISO  83278 
ISO  8327  AM3 

8.  DETAILED  DESCRIPTION 

The  support  of  the  OSI  TP,  CCR,  ACSE,  Presentation  and  Session  PDUs  for  ATP32  is  as 
described  in  Parts  1  -  4  of  this  standard. 

9.  CONFORMANCE 


Conformance  requirements  specified  in  ISO/IEC  ISP  12061-1,  ISO/IEC  ISP  12061-2,  ISO/IEC 
ISO/IEC  ISP  1 2061  -3,  ISP  1 2061  -4  apply  to  this  part. 

For  each  implementation  claiming  conformance  to  this  part  of  ISO/IEC  12061,  the  following  PICS 
Proformas  shall  be  completed  and  made  available  : 
•       ISO/IEC  10026-4  (OSI  TP) 
ISO/IEC  9805-2  (CCR) 
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ISO/IEC  8650-2  (ACSE) 

•  ISO/IEC  8823-2  (Presentation) 

•  ISO/IEC  8327-2  (Session) 
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15.12.  OIW  Application  Contexts 

1 5.1 2.1 .      Application  context  name 

Title:  UDT  with  Comnnit  Profiles 

Object  identifier:{iso(1)  identifiecl-organization(3)  oiw(14)  tpsig(15) 

application-context(5)  udt-with-CCR(l)  version  1(0)} 

1 5.1 2.1 .1 .  Purpose  and  Scope 

The  purpose  of  this  application  context  is  to  provide  the  TPSUs  participating  in  a  TP  dialogue 
with  a  mechanism  for  exchanging  unstructured  data  by  mapping  it  onto  an  APDU  consisting  of  a 
simple  octet  string.  A  bilateral  agreement  will  be  required  between  two  cooperating  TPSUIs 
using  this  context  since  the  syntax  and  semantics  of  the  application  protocol  are  not  defined  here. 

This  application  context  supports  both  application  and  provider  supported  transactions  executed 
serially  over  the  same  association. 

The  use  of  the  base  standards  identified  here  is  restricted  by  the  specification  of  the  OSI  TP 
profiles. 

15.12.1.2.  Referenced  Standards 

This  application  context  definition  references  in  whole  or  in  part  the  following  specifications: 

ISO/IEC  10026-3:1992,  Information  Technology  -  Open  Systems  Interconnection  -  Distributed 
Transaction  Processing  -  Part  3:  Protocol  specification 

ISO/IEC  10026-5:1992,  Information  Technology  -  Open  Systems  Interconnection  -  Distributed 
Transaction  Processing  Protocol  -  Part  5:  Application  Context  Proforma  and  Guidelines  When 
using  OSI  TP 

ISO/IEC  10026-6:1992,  Information  Technology  -  Open  Systems  Interconnection  -  Distributed 
Transaction  Processing  Protocol  -  Part  6:  Unstructured  Data  Transfer 

ISO/IEC  8650  Second  edition.  Information  Technology  -  Open  Systems  Interconnection  - 
Association  Control  Service  Element 

ISO/IEC  9805-1:1990,  Information  Technology  -  Open  Systems  Interconnection  -  Protocol 
Specification  for  Commitment,  Concurrency  and  Recovery  Service  Elements 

ISO/IEC  9805-1  AM2:1992,  Information  Technology  -  Open  Systems  Interconnection  -  Protocol 
Specification  for  Commitment,  Concurrency  and  Recovery  Service  Elements,  Amendment  2. 

ISO/IEC  PDISP  1 2061 ,  Information  Technology  -  Open  Systems  Interconnection  -  Distributed 
Transaction  Processing  ISP 


1 5.1 2.1 .2.1 .  Referenced  application  contexts 

None 
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1 5.1 2.1 .3.     Components  ASEs  and  ASOs 

The  following  ASEs  are  contained  in  this  application  context: 
ACSE 
TP-ASE 
CCR 
UDT 

15.12.1.3.1.  Association  Control  Service  Element  (ACSE) 

15.12.1.3.1.1.  References 

ISO/IEC  12061  part  4 

ISO/I  EC  8650  Second  Edition 

15.12.1.3.1.2.  Version  Number 

Version  1  of  the  ACSE  protocol  is  used. 

1 5.1 2.1 .3.1 .3.  Brief  description 

ACSE  is  used  to  establish  and  terminate  associations.  The  ACSE  functions  are  not  exercised 
directly  by  UDT  or  through  the  TP  service,  but  are  exercised  by  association  management 
facilities  within  the  TP  service  provider. 

15.12.1.3.2.  Distributed  Transaction  Processing  ASE  (TP-ASE) 

15.12.1.3.2.1.  References 

ISO/IEC  12061-2  and  12061-3 
ISO/IEC  10026-3 

15.12.1.3.2.2.  Version  Number 

Version  1  of  the  OSI  TP  protocol  is  used. 

1 5.1 2.1 .3.2.3.  Brief  description 

OSI  TP  provides  communications  mechanisms  for  the  support  of  processing  transactions  across 
two  or  more  separate  systems. 

15.12.1.3.3.  Commitment,  Concurrency  and  Recovery  (CCR) 
15.12.1.3.3.1.  References 

ISO/IEC  12061-3, 
ISO/IEC  9805-1  and 
ISO/IEC  9805-1  AM2 
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15.12.1.3.3.2.  Version  Number 

Version  2  of  the  OCR  protocol  is  used. 

15.12.1.3.3.3.  Brief  description 

OCR  is  used  in  support  of  the  commitment,  rollbacl<  and  recovery  functions.  Only,  TP  makes  use 
of  the  CCR  ASE  services. 

15.12.1.3.4.  Unstructured  Data  Transfer  ASE  (UDT) 

15.12.1.3.4.1.  References 

ISO/IEC  10026-6. 

15.12.1.3.4.2.  Version  Number 

Version  1  of  the  UDT  protocol  is  used. 

1 5.1 2.1 .3.4.3.  Brief  description 

This  ASE  transfers  unstructured  (i.e.  stmcture  unknown  to  the  TPPM)  data  between  cooperating 
TPSUIs. 

1 5.1 2.1 .3.4.4.  Use  of  other  ASEs  or  ASOs 

None 

1 5.1 2.1 .4.  Persistent  application  context  ruies 

None 

1 5.1 2.1 .5.  Control  function  rules 
15.12.1.5.1.  SACF  rules 

15.12.1.5.1.1.  Objective/summary 

There  are  no  SACF  njles  beyond  those  specified  in  the  base  standard,  ISO/IEC  10026-3. 

15.12.1.5.1.2.  Temporal  ordering  rules 

There  are  no  SACF  temporal  ordering  mles  beyond  those  specified  in  the  base  standard, 
ISO/IEC  10026-3  for  the  TP-DATA  generic  service. 

15.12.1.5.1.3.  Concatenation  rules 

There  are  no  SACF  concatenation  rules  beyond  those  specified  in  the  base  standard,  ISO/IEC 
10026-3. 
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15.12.1.5.1.4.  Mapping  rules 

The  UDT-TRANSFER-RI  APDU  may  be  mapped  onto  P-DATA,  the  User-Data  parameter  of  the 
TP-BEGIN-DIALOGUE  service,  or  the  User-Data  parameter  of  TP-U-ABORT  service.  There  are 
no  state  transitions  beyond  those  specified  in  the  base  standard,  ISO/IEC  10026-3  for  the  TP- 
DATA  generic  service. 

1 5.1 2.1 .5.1 .5.  References  to  base  rules 

ISO/IEC  10026-3 

1 5.1 2.1 .5.1 .6.  Other  rules 

None 

15.12.1.5.2.  MACF  rules 

15.12.1.5.2.1.  Objective/summary 

There  are  no  MACF  rules  beyond  those  specified  in  the  base  standard,  ISO/IEC  10026-3. 

15.12.1.5.2.2.  Temporal  ordering  rules 

There  are  no  MACF  sequencing  rules  beyond  those  specified  in  the  base  standard,  ISO/IEC 
10026-3. 

15.12.1.5.2.3.  Concatenation  rules 

There  are  no  MACF  concatenation  rules  beyond  those  specified  in  the  base  standard,  ISO/IEC 
10026-3. 

15.12.1.5.2.4.  Mapping  rules 

There  are  no  MACF  mapping  rules. 

1 5.1 2.1 .5.2.5.  References  to  base  rules 

ISO/IEC  10026-3 

1 5.1 2.1 .5.2.5.1 .      Other  rules 

None 

15.12.1.5.3.  Optional  features 

None 

15.12.1.5.4.  Error  handling 

For  this  application  context,  if  the  rules  and  constraints  of  the  application  context  are  violated  and 
the  commit  functional  unit  has  been  selected,  the  transaction  should  be  rolled  back.  If  the 
commit  functional  unit  is  not  selected,  the  TP-U-ERROR  service  may  be  used  or  the  dialogue 
may  be  aborted  depending  on  the  severity  of  the  error. 
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15.12.1.5.5.  Conformance 

Confonnance  to  this  application  context  consists  of  conformance  to  ISO/I  EC  PDiSP  12061  and 
ISO/IEC  10026-6. 

15.12.1.5.6.  Collision  handling 

No  collision  handling  rules  beyond  those  of  ISO/IEC  10026-3  are  required. 
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15.12.2.       Application  context  name 

Title:  Applicatbn  Supported  Transactions  using  UDT 

Object  identifier:{iso(1)  identified-organization(3)  oiw(14)  tpsig(15) 

application-context(5)  udt-without-CCR(2)  versfonl(O)} 

1 5.1 2.2.1 .  Purpose  and  Scope 

The  purpose  of  this  application  context  is  to  provide  the  TPSUs  participating  in  a  TP  dialogue 
with  a  mechanism  for  exchanging  unstmctured  data  by  mapping  it  onto  an  APDU  consisting  of  a 
simple  octet  string.  A  bilateral  agreement  will  be  required  between  two  cooperating  TPSUIs 
using  this  context  since  the  syntax  and  semantics  of  the  application  protocol  are  not  defined  here. 

This  application  context  supports  application  supported  transactions  executed  serially  over  the 
same  association. 

The  use  of  the  base  standards  identified  here  is  restricted  by  the  specification  of  the  OSI  TP 
profiles. 

15.12.2.2.  Referenced  Standards 

This  application  context  definition  references  in  whole  or  in  part  the  following  specifications: 

ISO/I  EC  10026-3:1992,  Information  Technology  -  Open  Systems  Interconnection  -  Distributed 
Transaction  Processing  -  Part  3:  Protocol  specification 

ISO/IEC  10026-5:1992,  Information  Technology  -  Open  Systems  Interconnection  -  Distributed 
Transaction  Processing  Protocol  -  Part  5:  Application  Context  Proforma  and  Guidelines  When 
using  OSI  TP 

ISO/IEC  10026-6:1992,  Information  Technology  -  Open  Systems  Interconnection  -  Distributed 
Transaction  Processing  Protocol  -  Part  6:  Unstructured  Data  Transfer 

ISO/IEC  8650  Second  edition,  Information  Technology  -  Open  Systems  Interconnection  - 
Association  Control  Service  Element 

ISO/IEC  PDISP 12061,  Information  Technology  -  Open  Systems  Interconnection  -  Distributed 
Transaction  Processing  ISP 


15.12.2.3.  Referenced  application  contexts 
None 

1 5.1 2.2.4.  Components  ASEs  and  ASOs 

The  following  ASEs  are  contained  in  this  application  context: 
ACSE 
TP-ASE 
UDT 


6 


Part  15  -  Transaction  Processing 


December  1992  (Stable) 


15.12.2.4.1.  Association  Control  Service  Element  (ACSE) 

15.12.2.4.1.1.  References 

ISO/IEC  12061  part  4 
ISO/IEC  8650  Second  Edition 

15.12.2.4.1.2.  Version  Number 

Version  1  of  the  ACSE  protocol  is  used. 

1 5.1 2.2.4.1 .3.  Brief  description 

ACSE  is  used  to  establish  and  terminate  associations.  The  ACSE  functions  are  not  exercised 
directly  by  UDT  or  through  the  TP  service,  but  are  exercised  by  association  management 
facilities  within  the  TP  service  provider. 

15.12.2.4.2.  Distributed  Transaction  Processing  ASE  (TP-ASE) 

15.12.2.4.2.1.  References 

ISO/IEC  1 2061  -2  and  1 2061  -3 
ISO/IEC  10026-3 

15.12.2.4.2.2.  Version  Number 

Version  1  of  the  OSI  TP  protocol  is  used. 

15.12.2.4.2.3.  Brief  description 

OSI  TP  provides  communications  mechanisms  for  the  support  of  processing  transactions  across 
two  or  more  separate  systems. 

15.12.2.4.3.  Unstructured  Data  Transfer  ASE  (UDT) 

15.12.2.4.3.1.  References 

ISO/IEC  10026-6. 

15.12.2.4.3.2.  Version  Number 

Version  1  of  the  UDT  protocol  is  used. 

1 5.1 2.2.4.3.3.  Brief  description 

This  ASE  transfers  unstructured  (i.e.  structure  unknown  to  the  TPPM)  data  between  cooperating 
TPSUIs. 

15.12.2.4.4.  Use  of  Other  ASEs  or  ASOs 

None 
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15.12.2.5. 


Persistent  application  context  rules 


None 


15.12.2.6. 


Control  function  rules 


15.12.2.6.1 


SACF  rules 


15.12.2.6.1.1. 


Objective/summary 


There  are  no  SACF  rules  beyond  those  specified  in  the  base  standard,  ISO/IEC  10026-3. 
15.12.2.6.1.2.        Temporal  ordering  rules 

There  are  no  SACF  tenfiporal  ordering  rules  beyond  those  specified  in  the  base  standard. 
ISO/IEC  10026-3  for  the  TP-DATA  generic  service. 


There  are  no  SACF  concatenation  rules  beyond  those  specified  in  the  base  standard.  ISO/IEC 
10026-3. 

15.12.2.6.1.4.  Mapping  rules 

The  UDT-TRANSFER-RI  APDU  may  be  mapped  onto  P-DATA.  the  User-Data  parameter  of  the 
TP-BEGIN-DIALOGUE  service,  or  the  User-Data  parameter  of  TP-U-ABORT  service.  There  are 
no  state  transitions  beyond  those  specified  in  the  base  standard.  ISO/IEC  10026-3  for  the  TP- 
DATA  generic  service. 

1 5.1 2.2.6.1 .5.  References  to  base  rules 

ISO/IEC  10026-3 

1 5.1 2.2.6.1 .6.  Other  rules 

None 

15.12.2.6.2.  MACF  rules 

1 5.1 2.2.6.2.1 .  Objective/summary 

There  are  no  MACF  rules  beyond  those  specified  in  the  base  standard,  ISO/IEC  10026-3. 

15.12.2.6.2.2.  Temporal  ordering  rules 

There  are  no  MACF  sequencing  rules  beyond  those  specified  in  the  base  standard.  ISO/IEC 
10026-3. 

15.12.2.6.2.3.  Concatenation  rules 

There  are  no  MACF  concatenation  rules  beyond  those  specified  in  the  base  standard.  ISO/IEC 
10026-3. 


15.12.2.6.1.3. 


Concatenation  rules 
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15.12.2.6.2.4.  Mapping  rules 

There  are  no  MACF  mapping  rules. 

15.12.2.6.2.5.  References  to  base  rules 

ISO/IEC  10026-3 

15.12.2.6.2.6.  Other  rules 

None 

15.12.2.6.3.  Optional  features 

None 

15.12.2.6.4.  Error  handling 

For  this  application  context,  if  the  rules  and  constraints  of  the  application  context  are  violated  the 
TP-U-ERROR  service  may  be  used  or  the  dialogue  may  be  aborted  depending  on  the  severity  of 
the  error. 

15.12.2.6.5.  Conformance 

Conformance  to  this  application  context  consists  of  conformance  to  ISO/IEC  PDISP  12061  and 
ISO/IEC  10026-6. 

15.12.2.6.6.  Collision  handling 

No  collision  handling  rules  beyond  those  of  ISO/IEC  10026-3  are  required. 
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Foreword  , 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Office  Document  Architecture 
Special  Interest  Group  (ODASIG)  of  the  Open  Systems  Environment  Implementors'  Workshop  (OIW). 

Text  in  this  part  has  been  approved  by  the  Plenary  of  the  above-mentioned  Worl<shop. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  change 
pages.  Deleted  and  replaced  text  will  be  shown  as  struckout.  New  and  replacement  text  will  be  shown  as 
shaded. 
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Part  16  -  Office  Document  Architecture  Level  3  DAP 


NOTE  -  Text  for  the  International  Standardized  Profile  11182-1  (F0D36)  follows  this  page. 

This  Agreement  provides  a  Document  Application  Profile  which  has  been  developed  through  the 
joint  efforts  of  ODA  expert  groups  within  the: 

OSE  Implementors'  Workshop  (OIW); 

Asia-Oceania  Workshop  (AOW); 

European  Workshop  for  Open  Systems  (EWOS); 

CCITT  Study  Group  VIII. 

This  effort  was  conducted  through  meetings  of  the  Profile  Alignment  Group  for  ODA  (PAGODA)  for 
the  purpose  of  facilitating  the  inten^^orking  of  applications  which  interchange  documents  based  on 
[ISO  8613  I  T.410  series  of  CCITT  Recommendations].  This  Agreement  specifies  one  of  the 
profiles  resulting  from  that  work: 

ISO/IEC  ISP  1 1 1 82-1 : 1 992,  Information  technology  -  Standardized  Profile  FOD36  -  Office  Document 
Format:  Extended  document  structure  -  Character,  raster  graphics  and  geomentric  graphics  content 
architectures  -  Document  Application  Profile. 


This  Agreement  accepts  the  entirety  of  the  definitions  and  provisions  of  this  ISP  as  the  agreement 
for  the  OIW  Stable  Agreements  and  the  standards  upon  which  the  specified  ISP  is  based  as 
referenced  by  the  text  of  the  ISP.  For  this  reason  the  text  of  the  ISP  is  not  reproduced  here,  but 
referenced  to  avoid  any  doubt  as  to  the  official  text  being  agreed  upon. 
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content  architectures  - 


Part  1  : 

Document  Application  Profile 
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Foreword 


Development  of  this  document  application  profile  has  been  done  in  liaison  with  several  organizations. 
These  include  ODA  expert  groups  within  the: 

—  Asia-Oceania  Workshop  (AOW); 

—  CCITT  Study  Group  VIII; 

—  European  Workshop  for  Open  Systems  (EWOS); 

—  OSE  Implementors  Workshop  (OIW). 

The  liaison  between  these  organizations  has  occurred  within  the  meetings  of  the  Profile  Alignment  Group 
for  ODA  (PAGODA).  These  meetings  have  focused  on  the  development  of  a  single  set  of  Internationally 
aligned  ODA  document  application  profiles. 

The  profile  defined  in  this  ISP  is  a  part  of  the  ODA  profile  taxonomy  defined  in  TR  10000-2,  4.4.4.3  and 
5.4.1.  This  profile  is  specific  to  the  profile  identifier  FOD36. 

At  present,  this  ISP  consists  of  one  part: 

Part  1:  Document  application  profile. 

Further  parts  may  be  added  to  this  ISP. 

This  part  contains  three  annexes: 

—  Annex  A  (normative):  Amendments  and  corrigenda: 

—  Annex  B  (informative):  Recommendations; 

—  Annex  C  (informative):  Bibliography. 
Introduction 

The  purpose  of  this  International  Standardized  Profile  (ISP)  |  CCITT  Recommendation  is  to  facilitate  the 
intenworking  of  applicattons  interchanging  documents  based  on  [ISO  8613  |  T.410  series  of  CCITT 
Recommendation],  ODA.  This  ISP  named  FOD36  |  CCITT  Recommendation  named  PM-36  is  suitable  for 
interchanging  documents  in  fonnatted  form,  processable  form  or  formatted  processable  form  and  has  been 
defined  in  accordance  with  [ISO  8613-1  |  CCITT  Recommendation  T.41 1].  The  format  of  this  profile  is  in 
accordance  with  the  standardized  proforma  and  notation  defined  in  Addendum  1  -  Annex  F  of  [ISO  8613-1 
I  CCITT  Recommendation  T.4111. 

The  specification  of  FOD36  is  identical  to  the  specification  of  PM-36,  except  that  PM-36  only  defines  the 
use  of  the  ODIF  interchange  format. 
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Character,  raster  graphics  and  geometric  graphics 
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DOCUMENTS  IN  PROCESSABLE,  FORMATTED  AND  FORMATTED 
PROCESSABLE  FORMS 

Document  Application  Profile 


1  Scope 

This  profile  specifies  interchange  formats  for  the  transfer  of  structured  documents  between  equipment 
designed  for  word  or  document  processing.  Such  documents  may  contain  character,  raster  graphics 
and  geometric  graphics  content. 

The  documents  that  can  be  interchanged  using  this  profile  range  from  sinple  documents  to  highly 
structured  technical  reports,  articles  and  typeset  documents  such  as  brochures.  This  profile  provides  a 
comprehensive  level  of  features  for  the  transfer  of  documents  between  these  systems. 

This  profile  allows  documents  to  be  interchanged  in  the  following  forms: 

a)  formatted  form; 

b)  processable  form; 

c)  formatted  processable  form. 

The  architecture  levels  defined  for  these  three  forms  have  matching  functionalities  so  that  the 
interchange  formats  of  a  document  are  convertible  from  a  processable  form  to  any  other  form. 

This  profile  is  independent  of  the  processes  carried  out  in  an  end  system  to  create,  edit  or  reproduce 
documents.  It  is  also  independent  of  the  means  to  transfer  documents  which,  for  example,  may  be  by 
means  of  communication  links  or  storage  media. 

( 

NOTE  1  -  The  following  texts  apply  to  the  ISP  only. 

A  document  structured  in  accordance  with  this  profile  is  represented  for  interchange  by  one  of  two 
DAPs.  One  DAP  uses  the  Office  Document  Interchange  Format  (ODIF),  the  other  DAP  uses  the  Office 
Document  Language  (ODL),  both  as  defined  in  ISO  8613-5. 

When  this  document  refers  to  this  profile,  it  is  referring  to  either  of  the  document  application  profiles 

defined  by  this  specification. 

) 


2  Normative  references 


The  following  documents  contain  provisions  which,  through  reference  in  this  text,  consititute  provisions 
of  this  Specification.  At  the  time  of  publication,  the  editions  indicated  were  valid.  All  documents  are 
subject  to  revision,  and  parties  to  agreements  based  on  this  Specification  are  warned  against 
automatically  applying  any  more  recent  editions  of  the  documents  listed  below,  since  the  nature  of 
references  made  by  profiles  to  such  documents  is  that  they  may  be  specific  to  a  particular  edition. 
Members  of  lEC  and  ISO  maintain  registers  of  currently  valid  International  Standards  and  ISPs.  The 
CCITT  secretariat  maintains  a  list  of  the  currently  valid  CCITT  recommendations. 

ISO  8613-1  :  1989,  Information  Processing  -  Text  and  Office  Systems;  Office  Document  Arctiitecture 
(ODA)  and  Interctiange  Format  -  Part  1:  Introduction  and  General  Principles, 

ISO  8613-2  :  1989.  Information  Processing  -  Text  and  Office  Systems:  Office  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  2:  Document  Structures, 

ISO  8613-4  :  1989,  Information  Processing  -  Text  and  Office  Systems;  Office  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  4:  Document  Profile: 

ISO  8613-5  :  1989,  Information  Processing  -  Text  and  Office  Systems:  Office  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  5:  Office  Document  Interchange  Format, 

ISO  8613-6  ;  1989,  Information  Processing  -  Text  and  Office  Systems:  Office  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  6:  Character  Content  Architectures; 

ISO  8613-7  :  1989.  Information  Processing  -  Text  and  Office  Systems:  Office  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  7;  Raster  Graphics  Content  Architectures; 

ISO  8613-8  :  1989,  Information  Processing  -  Text  and  Office  Systems:  Office  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  8;  Geometric  Graphics  Content  Architectures; 

ISO  8613-1  Addendum  1  :  Information  Processing  -  Text  and  Office  Systems;  Office  Document 
Architecture  (ODA)  and  Interchange  Format  Part  1:  Introduction  and  General  Principles  Addendum  1  - 
Annex  F  :  A  Document  Application  Profile  Proforma  and  Notation; 

CCITT  Recommendation  T.400  :  1988,  Introduction  to  Document  Architecture,  Transfer  and 
l^anipulation; 

CCITT  Recommendation  T.411  ;  1988,  Open  Document  Architecture  (ODA)  and  Interchange  Format- 
Introduction  and  General  Principles; 

CCITT  Recommendation  T.412  :  1988,  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Document  Structures; 

CCITT  Recommendation  T.414  :  1988,  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Document  Profile; 

CCITT  Recommendation  T.415  :  1988.  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Open  Document  Interchange  Format; 

CCITT  Recommendation  T.416  :  1988,  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Character  Content  Architecture; 

CCITT  Recommendation  T.417  :  1988,  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Raster  Graphics  Content  Architecture; 


2 


CCITT  Recommendation  T.418  : 1988.  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Geometric  Graphics  Content  Architecture; 

ISO/IEC  646  :  1991 ,  Information  technology  -  ISO  7-bit  coded  character  set  for  information  interchange, 

ISO  8859-1  :  1987.  Information  Processing  -  8-bit  Single-byte  coded  graphic  character  sets  -  Part  1: 
Latin  alphabet  No.  1; 

ISO  6937-2  : 1983,  Information  Processing  -  Coded  character  sets  for  text  communication  -  Part  2: 
Latin  alphabetic  and  non-alphabetic  graphic  characters; 

ISO  6937-2  ADDENDUM  1  :  1989,  Information  Processing  -  Coded  character  sets  for  text 
communication  -  PART  2:  Latin  alphabetic  and  non-alphabetic  graphic  characters  ADDENDUM  1; 

ISO  2022  : 1986,  Information  Processing  -  ISO  7-bit  and  8-bit  coded  character  sets  -  Code  extension 
techniques; 

ISO  2375  : 1985,  Data  Processing  -  Procedure  for  registration  of  escape  sequences; 

ISO  7350  : 1984,  Text  communication  ■  Registration  of  graphic  character  subrepertoires; 

ISO  8824  : 1987,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Abstract  Syntax 
Notation  One  (ASN.1); 

ISO  8825  : 1987,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Basic  encoding 
rules  for  abstract  syntax  notation  one  (ASN.  1); 

ISO  8879  :  1986,  Information  processing  -  Text  and  office  systems  -  Standard  Generalized  Markup 
Language  (SGML); 

ISO  9069  : 1988,  Information  processing  -  SGML  support  facilities  -  SGML  Document  Interchange 
Format  (SDIF); 

CCITT  Recommendation  T.502  |  ISO/IEC  ISP  10610-1  : 1992.  Information  technology  -  Standardized 
Profile  PM-11  /  F0D11  -  Open  Document  Format :  Simple  document  structure  -  Character  content 
architecture  only  -  Document  Application  Profile; 

CCITT  Recommendation  T.505  |  ISO/IEC  ISP  11181-1  : 1992.  Information  technology  -  Standardized 
Profile  PM-26  /  FOD26  -  Open  Document  Format :  Enhanced  document  structure  -  Character,  raster 
graphics  and  geometric  graphics  content  architectures  -  Document  Application  Profile; 

CCITT  Recommendation  T.516  :  (to  be  published)  Implementation  requirement  for  document  application 
profile  PM-36; 

ISO/IEC  TR  10000-1  :  1990,  Information  Technology  -  Framework  and  Taxonomy  of  International 
Standardized  Profiles  -  Pan  1:  Framework; 

ISO/IEC  TR  10000-2  : 1990,  Information  Technology  -  Framework  and  Taxonomy  of  Intemational 
Standardized  Profiles  -  Part  2:  Taxonomy, 
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3  Definitions 


For  the  purposes  of  this  Specification,  the  following  definitions  apply. 

The  definitions  given  in  [ISO  8613-1  |  CCITT  Recommendation  T.411]  are  applicable. 

Constituent  names 

Each  constituent  that  may  be  included  in  a  document  that  conforms  to  this  profile  has  been  given  a 
unique  name  which  serves  to  identify  that  constituent  throughout  this  profile. 

The  convention  is  tnat  full  names  are  used  (i.e.,  no  abbreviations  are  used),  two  or  more  words  in  a 
name  are  concatenated  and  each  word  t>egins  with  a  capital.  Examples  of  constituent  names  used  In 
this  profile  are  BodyText,  Footnote,  RectoPage  and  ColumnFixed. 

In  clause  6,  each  constituent  provided  by  this  profile  is  underlined  once  at  the  point  in  the  text  at  which 
the  purpose  of  that  constituent  is  defined.  This  also  serves  to  identify  all  the  constituents  provided  by 
this  profile. 

The  same  constituent  names  are  also  used  in  the  technical  specification  in  clause  7  so  that  there  Is  a 
one-to-one  correspondence  between  the  use  of  these  names  in  clauses  6  and  7. 

Although  the  constituent  names  relate  to  the  purpose  of  the  constituents,  the  semantics  of  constituents 
shall  not  be  implied  from  the  actual  names  that  are  used.  Also,  these  names  do  not  appear  in  an 
interchanged  document  but  a  mechanism  for  identifying  constituents  in  an  interchange  document  is 
provided  (see  6.6.5).  Thus  in  an  application  using  this  profile,  the  constituents  may  t>e  l<nown  to  the 
user  by  different  names. 


4  Relationship  with  other  profiles 

This  profile  belongs  to  a  series  of  hierarchically  related  profiles  which  include  PM-11  |  F0D11  and  PM- 
26  I  FOD26. 

The  features  supported  by  this  profile  are  a  superset  of  the  features  supported  by  the  profiles  PM-1 1  | 
F0D11  and  PM-26  |  FOD26  and  thus  all  data  streams  that  are  conformant  to  PM-11  |  F0D11  and  PM- 
26  I  FOD26  are  also  conformant  to  this  profile  apart  from  the  DAP  identifier. 


5  Conformance 

In  order  to  conform  to  this  profile,  a  data  stream  representing  a  document  must  meet  the  requirements 

specified  in  5.1 .         .  a  < 

( 

NOTE  2  -  The  following  text  applies  to  the  ISP  only. 

This  part  of  the  ISP  does  not  define  implementation  support  requirements.  These  requirements  are 
defined  in  other  parts  that  make  use  of  this  ISP. 

-)  . 
{ 

NOTE  3  -  The  following  text  applies  to  the  CCITT  Recommendations  only. 

This  Recommendation  does  not  define  implementation  or  service  requirements.  These  requirements 
are  defined  in  other  Recommendations  that  make  use  of  this  profile. 
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5.1  Data  stream  conformance 


The  following  requirements  apply  to  the  encoding  of  data  streams  which  conform  to  this  profile: 

a)  (NOTE  4  -  The  following  text  applies  to  the  ISP  only. 

the  data  stream  shall  be  encoded  either  in  accordance  with  the  ASN.1  encoding  rules  defined 
in  [ISO  8825  |  CCITT  Recommendation  X.209]  or  the  SGML  encoding  rules  defined  in  ISO 
8879; 
) 

(NOTE  5  -  The  following  text  applies  to  CCITT  Recommendation  only. 

the  data  stream  shall  be  encoded  in  accordance  with  the  ASN.1  encoding  rules  defined  in 

[CCITT  Recommendation  X.209  |  ISO  8825]; 

) 

b)  the  data  stream  shall  be  structured  in  accordance  with  the  interchange  formats  defined 
in  clause  8; 

c)  the  document,  as  represented  by  the  data  stream  after  resolution  of  any  external 
references,  shall  be  structured  in  accordance  with  one  of  the  documents  architecture 
classes  as  defined  in  6.1  and  shall  contain  all  mandatory  constituents  specified  for  that 
class;  other  constituents  may  be  included,  provided  that  they  are  permitted  for  that 
class  as  specified  in  clause  7; 

d)  each  constituent  shall  contain  all  those  attributes  specified  as  required  for  that 
constituent  in  this  profile;  other  attributes  may  be  specified  provided  that  they  are 
permitted  for  that  constituent; 

e)  the  attribute  values  specified  shall  be  within  the  range  of  permissible  values  specified  in 
this  profile; 

f)  the  encoded  document  shall  be  constructed  in  accordance  with  the  abstract  document 

architecture  defined  in  [ISO  8613-2  |  CCITT  Recommendation  T.412]; 

g)  the  document  shall  be  structured  in  accordance  with  the  characteristics  and  constraints 
specified  in  clause  6. 


5.2  Implementation  conformance 

This  subclause  states  the  requirements  for  implementations  claiming  conformance  to  this  profile. 

( 

NOTE  6  -  The  following  text  applies  to  the  ISP  only. 

A  conforming  receiving  implementation  shall  be  capable  of  receiving  either  any  data  streams 
conforming  to  this  profile  structured  in  accordance  with  ODIF,  or  any  data  streams  conforming  to  this 
profile  stmctured  in  accordance  with  ODL  or  both  of  these.  Receiving  usually,  but  not  always,  involves 
recognizing  and  further  processing  the  data  stream  elements.  The  explicit  meaning  of  "receiving"  is 
determined  by  another  part  of  this  ISP. 
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A  receiving  system  which  claims  conformance  to  this  DAP  shall  be  capable  of  handling  data  streams 

which  are  conformant  to  DAPs  that  are  subordinate  to  this  DAP  within  the  taxonomy  described  in 

clause  4.  i.e.  FOD11  and  FOD26. 

) 

( 

NOTE  7  -  The  following  text  applies  to  the  ISP  only. 


The  implementation  requirements  associated  with  this  profile  are  defined  in  Recommendation  T.516. 
) 


6  Characteristics  supported  by  this  document  application  profile 

9 

This  clause  describes  the  characteristics  of  documents  which  may  be  represented  by  data  streams 
conforming  to  this  profile.  This  clause  also  describes  how  these  characteristics  are  represented  in 
terms  of  constituent  constraints. 

6.1  Overview 

6.1.1  General 

This  profile  supports  the  interchange  of  documents  in  the  following  forms: 

—  processable  form,  which  facilitates  the  revision  of  a  document  by  a  recipient; 

—  formatted  form,  which  facilitates  the  reproduction  of  a  document  as  intended  by  the 
originator; 

—  formatted  processable  form,  which  facilitates  the  reproduction  of  a  document  as 
intended  by  the  originator  or  facilitates  the  revision  of  a  document  by  a  recipient; 

In  addition  this  profile  supports  the  interchange  of: 

—  generic-document; 

—  document  profile. 

The  constituents  that  make  up  these  five  classes  of  data  stream  are  defined  in  6.1.2  to  6.1 .6. 
Constituents  defined  as  required'  shall  occur  in  any  data  stream  that  conforms  to  this  profile. 
Constituents  listed  as  optional'  may  or  may  not  be  present  in  the  data  stream  depending  on  the 
requirements  of  the  particular  data  stream. 

NOTE  8  -  The  constituents  that  make  up  a  complete  data  stream  that  is  conformant  to  this  profile  includes  all 
•  those  referenced  and  contained  in  resource  and  external  documents,  if  any  (see  6.6.1  and  6.6.2). 

6.1.2  Formatted  form  documents 

Required  constituents: 

—  a  document  profile; 

—  layout  object  descriptions  representing  a  specific  layout  structure. 
Optional  constituents: 
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—  layout  object  class  descriptions  representing  a  'factor*  generic  layout  stmcture; 

—  presentation  styles; 

—  content  portion  descriptions. 

6.1.3  Processable  form  documents 

Required  constituents: 

—  a  document  profile; 

—  logical  object  class  descriptions  representing  a  complete'  or  partial'  generic  logical 
structure; 

—  bgical  object  descriptions  representing  a  specific  logical  structure. 
Optional  constituents: 

—  layout  object  class  descriptions  representing  a  'complete'  generic  layout  structure; 

—  layout  styles; 

—  presentation  styles; 

—  content  portion  descriptions. 

In  the  case  of  processable  form  documents,  when  the  generic  layout  structure  is  not  present,  additional 
restrictions  are  placed  on  the  layout  directives  that  may  be  included  in  layout  styles.  These  restrictions 
are  defined  in  6.4.3  of  this  profile. 

6.1.4  Fomfiatted  processable  form  documents 

Required  constituents: 

—  a  document  profile; 

—  logical  object  class  descriptions  representing  a  'complete'  or  'partial'  generic  logical 
stmcture; 

—  logical  object  descriptions  representing  a  specific  logical  structure; 

—  layout  object  class  descriptions  representirtg  a  'complete'  generic  layout  structure; 

—  layout  object  descriptions  representing  a  specific  layout  stmcture. 
Optional  constituents: 

—  layout  styles; 

—  presentation  styles; 

—  content  portion  descriptions. 
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6.1.5  Generic  documents 

A  generic-ck)cument  consists  of  one  of  the  following  sets  of  constituents: 
a) 

—  a  document  profile; 

—  logical  object  class  descriptions  whicti  represent  a  'complete'  or  partial'  generic  logical 
structure; 

—  layout  styles  whose  presence  is  optional; 

—  presentation  styles  whose  presence  is  optional; 

—  generic  content  portions  whose  presence  is  optional. 

b) 

—  a  document  profile; 

—  layout  object  class  descriptions  which  represent  a  complete'  generic  layout  structure  or 
'factor  set"; 

—  presentation  styles  whose  presence  is  optional; 

—  generic  content  portions  whose  presence  is  optional. 

c) 

—  a  document  profile; 

—  logical  object  class  descriptions  which  represent  a  'complete'  or  partial'  generic  logical 
structure; 

—  layout  object  class  descriptions  which  represent  a  'complete'  generic  layout  structure; 

—  layout  styles  whose  presence  is  optional; 

—  presentation  styles  whose  presence  is  optional; 

—  generic  content  portions  whose  presence  is  optional. 

6.1.6  Document  profile 

This  form  of  document  contains  a  document  profile  only. 
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6.2  Logical  characteristics 


6.2.1  Introduction 

This  subclause  defines  the  logical  constituent  constraints  provided  by  this  profile  to  represent  the 
characteristics  of  documents. 

Different  constituent  constraints  may  be  used  to  represent  and  distinguish  parts  of  a  document  that 
have  different  logical  characteristics.  This  subclause  describes  the  general  characteristics  and  typical 
uses  of  the  constituent  constraints  that  are  provided. 

The  descriptions  of  the  togical  characteristics  represented  by  each  of  the  constituent  constraints  is 
provided  for  guidance  only.  It  is  the  responsibility  of  the  user  to  determine  how  a  document  Is  to  be 
represented  using  the  constituents  provided.  Adherence  to  these  guidelines  can  enhance  the  mutual 
understanding  of  a  document  by  an  originator  and  a  recipient. 


6.2.2  Overview  of  the  logical  structure 

From  the  logical  point  of  view,  the  document  consists  of  two  parts,  namely  a  'body'  part  and  a 
'common'  part. 

The  body'  part  represents  the  main  content  of  a  document  and  is  intended  to  be  reproduced  In  the 
body  area  of  the  pages  that  make  up  the  document.  The  body'  part  must  be  included  in  all  documents 
that  are  interchanged  in  accordance  with  this  profile. 

The  common'  part  represents  common  content  that  is  to  be  placed  in  reserved  header  and  footer 
areas  on  each  page  of  a  document.  Header  and  footer  content  are  independently  optional  and  so  may 
be  included  in  an  interchanged  document  only  if  required. 

6.2.3  Body  pan  of  trie  logical  structure 
6.2.3.1  DocumentLogicalRoot 

Docume ntLog ical Root  is  a  constituent  constraint  representing  the  top  level  in  the  document  logical 
structure.  Its  immediate  sutwrdinates  consist  of  an  arbitrary  ordered  sequence  of  one  or  more 
constituent  constraints  of  the  types  Passage  and  NumberedSegment. 

The  automatic  numbering  schemes  that  apply  to  constituent  constraints  of  the  types 
NumberedSegment,  Figure,  Table,  NumberedList  and  Footnote  may  be  initialized  on  the 

DocumentLogicalRoot. 


6.2.3.2  Passage 

Passage  is  a  constituent  constraint  that  represents  a  subdivision  of  a  document  that  corresponds  to  a 
logical  grouping  of  subordinate  parts  of  a  document.  This  grouping  may  be  regarded  as  a  logical  entity 
for  reading,  or  It  may  represent  parts  of  a  document  that  have  common  layout  and  presentation 
characteristics. 

Passages  are  typically  used  to  represent: 
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—  the  contents  to  be  placed  on  the  title  page  of  a  report; 

—  the  front  matter,  consisting  of  the  table  of  contents  or  foreword; 

—  the  main  matter  of  the  document; 

—  the  back  matter,  consisting  of  appendices,  glossary  or  index; 

—  an  illustration  with  associated  text  which  is  inserted  as  a  distinct  entity  within  a  section 
of  a  document. 

The  automatic  numbering  schemes  that  apply  to  subordinate  constituent  constraints  of  the  types 
NumberedSegment,  Figure,  Table,  NumberedList  and  Footnote  may  be  initialized  on  a  Passage. 

The  immediate  subordinates  of  a  Passage  consist  of  an  optional  constituent  constraint  of  the  type  Title 
which  is  followed  by  an  arbitrary  ordered  sequence  of  one  or  more  of  the  following  constituent 
constraints; 

—  Paragraph; 

—  BodyGeometric; 

—  BodyRaster; 

—  BodyText; 

—  Figure; 

—  Table; 

—  NumberedList; 

—  UnNumberedList; 

—  DefinitionList; 

—  NumberedSegment; 

—  Passage. 

A  Passage  shall  have  at  least  one  of  the  above  constituent  constraints  as  a  sutx)rdinate. 

Therefore,  a  Passage  may  itself  contain  one  or  more  sutx)rdinates  of  the  type  Passage,  and  thus 
Passages  may  be  nested  to  any  number  of  levels.  This  allows  logical  entities  within  a  document  to  be 
described  in  terms  of  their  component  logical  entities.  Also,  a  NumberedSegment  may  contain  one  or 
more  sutwrdinate  Passages  which  allows  different  logical  entities  within  a  NumberedSegment  to  be 
distinguished. 

A  document  may  contain  several  different  class  definitions  of  the  type  Passage,  each  of  which  defines 
the  common  characteristics  of  sets  of  Passages  within  the  document,  such  as  their  allowed 
subordinates  or  layout  properties.  For  example,  a  class  of  Passages  may  be  defined  which  always 
begins  on  a  new  page  set. 
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6.2.3.3  NumberedSegment 


NumberedSegment  is  a  constituent  constraint  that  represents  a  logical  entity  within  a  document  that  is 
distinguished  by  an  identifier.  This  logical  entity  may  be  a  subdivision  of  a  document  or  a  higher  level 
Passage  or  NumberedSegment.  The  entity  may  also  be  distinguished  by  having  some  comnwn  layout 
characteristics. 

The  automatic  numbering  schemes  that  apply  to  the  subordinate  constituent  constraints 
NumberedSegment,  Figure,  Table,  NumberedUst  and  Footnote  may  be  initialized  on  any  logical  object 
or  logical  object  class,  typically  on  Passage  or  a  NumberedSegment. 

The  immediate  subordinates  of  a  NumberedSegment  consist  of  the  constituent  constraint  Number 
whose  presence  is  mandatory  and  serves  to  carry  the  identifier  of  the  NumberedSegment.  This  is 
followed  optionally  by  a  constituent  constraint  Title  which  in  turn  is  followed  by  an  optional  arbitrary 
ordered  sequence  of  one  or  more  of  the  following  constituent  constraints: 

—  Paragraph; 

—  BodyGeometric; 

—  BodyRaster; 

—  BodyText; 

—  Figure; 

—  Table; 

—  NumberedList; 

—  UnNumberedList; 

—  DefinitionList; 

—  Passage; 

—  NumberedSegment. 

The  at>ove  indicates  that  a  document  may  contain  any  number  of  nested  levels  of  the  constituent 
constraint  NumberedSegment. 

A  NumberedSegment  is  typically  used  to  represent  entities  such  as  chapters,  sections,  nested  sub- 
sections and  appendices  which  contain  an  identifier  that  serves  to  distinguish  that  entity  for  human 
comprehension. 

A  document  may  contain  any  numt)er  of  different  class  definitions  of  NumberedSegment  which  define 
the  common  characteristics  of  sets  of  NumberedSegments,  such  as  their  allowed  subordinates  and 
layout  properties. 

Class  definitions  of  Numl>eredSegments  may  be  recursively  defined.  In  this  case,  only  one  class  of 
NumberedSegment  may  t>e  specKied,  and  the  <simple-expr>  construction  in  the  macro 
USENUMBERSTRINGS  in  the  bindings  attribute  of  this  class  shall  use  the  optional  ORD  construction 
only.  If  recursive  class  definitions  are  used  for  NumberedSegment,  the  following  constraints  will  also 
apply.  For  all  levels  which  reference  recursively  defined  classes: 
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—  numbering  format  will  be  the  same; 

—  no  initial  value  other  than  1  or  re-initialization  of  the  numt)ering  is  possible; 

—  it  is  not  possible  to  continue  the  numbering  across  Passages. 


6.2.3.4  Number 

Numt)er  is  a  constituent  constraint  that  represents  the  identifier  of  a  NumberedSegment,  Figure  or 
Numt>eredList  to  which  it  is  subordinate.  This  identifier  allows  the  superior  constituent  constraint  to 
which  it  belongs  to  t>e  distinguished  within  the  document  for  machine  processing  or  human 
comprehension. 

A  Numt)er  is  a  basic  logical  constituent  constraint  which  contains  a  content  generator  which,  when 
evaluated,  produces  the  identifier  referred  to  above.  This  evaluation  takes  place  during  the  layout 
process.  • 

The  identifiers  are  stmctured  and  consist  of  a  sequence  of  one  or  more  numerals  that  allow 
Numt)eredSegments  at  the  same  or  different  levels  in  a  document  structure  to  be  uniquely 
distinguished.  The  numerals  may  be  represented  by  Arabic  or  Roman  numerals  or  by  their  alphabetic 
equivalent  in  lower  or  upper  case  characters  (the  number  1  is  represented  by  A",  etc.).  Each  numeral 
in  an  identifier  is  distinguished  by  means  of  separator'  characters  such  as  spaces  and  full  stops  (the 
character  'period');  a  typical  example  is  '6.2.3.4'. 

NOTE  9  -  The  separator  rtiay  be  an  empty  string. 

Further  details  of  the  structure  and  generation  of  the  identifiers  are  given  in  6.6.7. 


6.2.3.5  THIe 

Title  is  a  constituent  constraint  that  is  used  to  represent  the  title,  heading  or  name  of  the  Passage  or 
NumberedSegment  to  which  it  is  an  immediate  subordinate.  This  constituent  constraint  may  consist  of 
character,  raster  graphics  and  geometric  graphics  content. 

The  immediate  sut>ordinates  of  this  constituent  constraint  consist  of  an  arbitrary  ordered  sequence  of 
one  or  more  of  the  following  constituent  constraints: 

—  Body  Text; 

—  BodyRaster; 

—  BodyGeometric; 

—  Phrase; 

—  Reference; 

—  Footnote. 

The  character  content  associated  with  a  Title  may  be  concatenated  to  form  a  continuous  stream  of 
character  content  which  may  contain  single  or  multiple  references  to  footnotes  or  other  parts  of  the 
document,  and  may  be  laid  out  as  single  unit.  Entities  within  this  content  which  have  particular  logical 
significance  or  presentation  features  may  be  distinguished  using  the  constituent  constraint  Phrase. 
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Content  from  any  sutx)rclinate  basic  text  objects  within  a  paragraph  may  be  run-on  one  from  another 
(that  is,  to  continue  on  the  same  line)  by  use  of  Concatentation  (see  6.4.2.5).  Alternatively,  content 
from  subordinates  of  a  paragraph  may  be  separated  one  from  another  to  give  white  space  between 
them,  using  Separation  (see  6.4.2.2).  This  may  be  used  to  give  an  effect  similar  to  that  achieved  with 
empty  lines  of  text.  Use  of  empty  text  lines  to  achieve  white  space  between  areas  of  text  or  other 
content  may  lead  to  unintended  blank  areas  adjacent  to  the  leading  edge  of  layout  objects,  whereas  the 
use  of  Separation  avoids  this. 


6.2.3.6  Paragraph 

Paragraph  is  a  constituent  constraint  that  is  a  subdivision  of  a  Passage  or  NumberedSegment.  It  is 
typically  used  to  represent  the  grouping  of  parts  of  a  document  that  deals  with  a  single  theme  or  topic. 
These  parts  may  consist  of  character,  raster  graphics  and  geometric  graphics  content. 

The  immediate  subordinates  of  a  Paragraph  consist  of  an  arbitrary  ordered  sequence  of  one  or  more  of 
the  following  constituent  constraints: 

—  BodyText; 

—  BodyRaster; 

—  BodyGeo  metric; 

—  Phrase; 

—  Reference; 

—  Footnote. 

The  character  content  associated  with  a  Paragraph  may  be  concatenated  to  form  a  continuous  stream 
of  character  content  which  may  contain  single  or  multiple  references  to  footnotes  or  other  parts  of  the 
document,  and  may  be  laid  out  as  single  unit.  Entities  within  this  content  which  have  particular  logical 
significance  or  presentation  features  may  be  distinguished  using  the  constituent  constraint  Phrase. 

Content  from  subordinates  of  a  paragraph  may  be  separated  one  from  another  to  give  white  space 
between  them  using  Separation  (see  6.4.2.2).  This  may  be  used  to  give  an  effect  similar  to  that 
achieved  with  empty  lines  of  text.  Use  of  empty  text  lines  to  achieve  white  space  between  areas  of  text 
or  other  content  may  lead  to  unintended  blank  areas  adjacent  to  the  leading  edge  of  layout  objects 
(e.g.,  at  page  breaks)  whereas  the  use  of  Separation  avoids  this 

6.2.3.7  Phrase 

Phrase  is  a  constituent  constraint  that  is  used  to  group  together  an  amount  of  character  content  that 
represents  a  single  logical  entity  that  needs  to  be  distinguished  for  some  purpose.  That  is,  the  content 
represented  by  a  Phrase  may  have  a  particular  logical  significance,  or  it  may  have  certain  layout  or 
presentation  requirements.  The  character  content  may  contain  embedded  footnotes  and  references  to 
other  parts  of  the  document  content.  A  typical  example  is  a  quotation  that  is  to  be  reproduced  in  Italics. 

A  Phrase  may  be  used  as  subdivision  of  constituent  constraints  of  the  types  Paragraph,  Title,  Caption, 
Description.  Artwork  and  Listltem.  Also,  a  Phrase  may  be  sutxDrdinate  to  another  Phrase  and. 
therefore,  constituent  constraints  of  the  type  Phrase  may  be  nested. 

The  immediate  subordinates  of  this  constituent  constraint  consist  of  an  arbitrary  ordered  sequence  of 
one  or  more  of  the  following  constituent  constraints: 
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—  BodyText; 


—  Phrase; 

—  Reference; 

—  Footnote. 

The  character  content  associated  with  a  Phrase  may  be  concatenated  to  form  a  continuous  stream  of 
character  content  which  may  contain  single  or  multiple  references  to  footnotes  or  other  parts  of  the 
document,  and  may  be  laid  out  as  single  unit.  Alternatively,  the  character  content  may  contain  hard 
line  terminators,  which  will  cause  parts  of  the  content  to  be  separated  when  laid  out. 


6.2.3.8  BodyText,  BodyRaster  and  BodyGeometric 

BodyText.  BodyRaster  and  BodyGeometric  are  constituent  constraints  which  represent  the  lowest  level 
of  logical  subdivision  of  a  document.  These  constituent  constraints  act  as  carriers  for  the  document 
content  and  may  be  specified  as  subordinates  of  constituent  constraints: 

—  Passage; 

—  NumberedSegment; 

—  Paragraph; 

—  Title; 

—  ListTerm; 

—  Artwork; 

—  Phrase; 

—  Reference; 

—  UnNumberedList. 

In  addition,  BodyText  may  be  specified  as  a  sut)ordinate  to  Phrase,  Caption  and  Description.  These 
constituent  constraints  allow  the  layout  and  presentation  requirements  of  different  parts  of  the  content  of 
a  document  to  be  specified. 

These  are  basic  logical  constituent  constraints  that  directly  refer  to  content  portions  that  contain 
character,  raster  graphics  and  geometric  graphics  content  respectively.  BodyText  shall  refer  to  one  or 
more  content  portions  which  may  contain  either  processable,  formatted  or  formatted  processable 
character  content.  BodyRaster  and  BodyGeometric  shall  only  refer  to  a  single  content  portion 
containing  formatted  processable  raster  graphics  content  or  formatted  processable  geometric  graphics 
content  respectively. 

These  constituent  constraints  in  the  generic  logical  structure  may  refer  to  generic  content.  This 
provides  the  means  of  defining  common  content  within  the  body  part  of  a  document. 

Where  the  superior  constituent  constraint  referenced  is  subordinate  to  a  FootnoteBody,  it  is  required  to 
specify  one  of  the  layout  category  names  for  this  constituent  constraint.  Footnote'  or  'Footnote-<n>'. 
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This  along  with  a  Permitted  categories  attribute  of  the  same  name  on  the  footnote  frame  will  ensure 
that  a  logical  object  from  this  constituent  constraint  is  laid  out  in  a  FootnoteArea  frame  when  generic 
layout  structure  is  specified  within  the  document. 

6.2.3.9  Constituents  representing  footnotes 

This  sutx;lause  defines  the  constituents  that  are  used  to  represent  footnotes. 
6.2.3.9.1  Footnote 


Footnote  is  a  constituent  constraint  that  is  used  to  represent  footnotes  within  a  document.  This 
constituent  constraint  may  be  specified  as  a  sutwrdinate  to: 

—  Paragraph; 

—  Title; 

—  ListTerm; 

—  Phrase; 

—  Caption; 

—  Description. 


A  footnote  is  an  amount  of  content  that  is  logically  associated  with  a  particular  part  of  the  document 

body,  but  which  is  intended  to  be  read  and  laid  out  separately  from  its  associated  part  of  the  document.  ^  ^ 

Typically,  a  footnote  consists  of  a  footnote  identifier,  which  is  embedded  within  the  document  lx)dy,  and 

the  footnote  itself,  which  is  laid  out  elsewhere. 


A  Footnote  is  a  composite  logical  constituent  constraint  whose  immediate  subordinates  consist  of  the 
constituent  constraint  FootnoteReference,  which  represents  the  footnote  identifier,  followed  by  the 
constituent  constraint  FootnoteBody.  which  represents  the  footnote  itself.  Both  of  these  subordinates 
are  mandatory. 

6.2.3.9.2  FootnoteReference 


FootnoteReference  is  a  constituent  constraint  that  is  used  to  represent  a  footnote  reference  within  the 
body  of  a  document. 

FootnoteReference  is  a  basic  logical  constituent  that  contains  a  content  generator  which,  when 
evaluated,  produces  a  character  string  which  constitutes  the  footnote  reference  referred  to  above. 

The  generated  character  string  consists  of  a  label  with  optional  prefix  and  suffix  character  strings.  The 
lat>el  is  used  to  uniquely  identify  a  particular  footnote,  and  may  consist  of  a  number  which  is 
represented  in  the  form  of  Arabic  or  Roman  numerals  or  by  an  alphabetic  equivalent.  The  number  may 
t)€  automatically  generated  so  that  its  value  is  incremented  for  each  successive  footnote.  Alternatively, 
the  lat>el  may  consist  of  a  user  defined  character  string. 

In  a  sequence  of  footnotes,  automatic  numbers  and  user  defined  labels  may  be  freely  mixed  (for 

example,  giving  the  sequence  1,2, •,3,4).  If  the  label  consists  of  a  user-defined  character  string,  the  f  \ 

automatically  generated  numt)er  sequence  is  not  incremented.  XT' 
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An  example  of  a  footnote  reference  is  '(2)'  where  '('  and  ')'  are  user  defined  prefix  and  suffix  strings 
respectively  and  '2'  is  tfie  automatically  generated  label.  Anotfier  example  is  note^'  wfiere  '5'  is  ttie 
label  and  note'  is  a  prefix  string  wfiich  also  contains  the  control  function  PLU  to  enable  the  label  to  be 
represented  in  the  form  of  a  superscript.  In  this  case,  a  suffix  string  containing  the  control  function  PLD 
would  be  required  to  cause  the  superscripting  to  be  cancelled  before  the  following  text. 

The  format  of  the  content  generator  referred  to  at>ove  is  described  in  6.6.7.7. 


6.2.3.9.3  FootnoteBody 

FootnoteBodv  is  a  constituent  constraint  which  represents  the  content  of  a  footnote.  The  content 
consists  of  a  stream  of  character  content  which  may  contain  embedded  references  to  other  parts  of  the 
document. 

FootnoteBody  is  a  composite  logical  constituent  constraint  whose  subordinates  consist  of  the 
constituent  constraint  FootnoteNumber,  which  is  mandatory  and  represents  the  footnote  identifier, 
followed  by  a  sequence  of  one  or  more  constituent  constraints  of  the  type  FootnoteText  and  Reference 
which  represent  the  footnote  content.  The  identifier  refen-ed  to  above  is  identical  to  the  corresponding 
footnote  identifier  which  is  embedded  in  the  content  of  the  document  body  and  represented  by  the 
constituent  constraint,  FootnoteReference. 

The  constituent  constraints  subordinate  to  FootnoteBody  are  intended  to  be  laid  out  separately  from  the 
other  parts  of  the  document  content.  When  a  generic  layout  structure  is  specified  for  the  document, 
these  constituent  constraints  are  constrained  to  be  laid  out  in  a  FootnoteArea  frame  (see  6.3.5.20). 


6.2.3.9.4  FootnoteNumber 

FootnoteNumber  is  a  constituent  constraint  that  represents  the  footnote  identifier  within  the  footnote 
body. 

This  identifier  is  identical  to  the  content  associated  with  the  constituent  constraint  FootnoteReference, 
but  is  intended  to  be  laid  out  so  that  it  immediately  precedes  the  content  of  the  footnote  body. 

FootnoteNumber  is  a  basic  logical  constituent  constraint  that  contains  a  content  generator  which  when 
evaluated  produces  the  identifier  referenced  above.  The  format  of  this  content  generator  is  the  same 
as  the  content  generator  that  may  be  specified  for  the  constituent  constraint  FootnoteReference. 

It  is  required  to  specify  one  of  the  layout  category  names  for  this  constituent  constraint,  'Footnote'  or 
'Footnote-<n>'.  This  along  with  a  permitted  categories  attribute  of  the  same  name  on  the  footnote 
frame  will  ensure  that  a  logical  object  from  this  constituent  constraint  is  laid  out  in  a  FootnoteArea 
frame  when  generic  layout  structure  is  specified  within  the  document. 


6.2.3.9.5  FootnoteText 

FootnoteText  is  a  constituent  constraint  that  is  used  to  represent  the  footnote  content.  It  is  the  lowest 
logical  subdivision  of  a  FootnoteBody. 

FootnoteText  is  a  basic  logical  constituent  constraint  that  references  one  or  more  content  portions  each 
containing  processable,  formatted  or  formatted  processable  character  content. 
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It  is  required  to  specify  one  of  the  layout  category  names  for  this  constituent  constraint,  'Footnote'  or 
'Footnote-<n>'.  This  along  with  a  permitted  categories  attribute  of  the  same  name  on  the  footnote 
frame  will  ensure  that  a  logical  object  from  this  constituent  constraint  is  laid  out  in  a  FootnoteArea 
frame  when  generic  layout  structure  is  specified  within  the  document. 


6.2.3.10  Constituents  that  provide  for  a  general  referencing  mechanism 

This  subclause  defines  the  constituent  constraints  that  are  provided  to  support  a  general  referencing 
mechanism  in  a  document. 


6.2.3.10.1  Reference 

A  Reference  is  a  constituent  constraint  which  represents  a  reference  consisting  of  character  content 
that  is  derived  either  fully  or  partially  from  another  part  of  the  document.  This  constituent  constraint 
provides  a  general  cross-referencing  mechanism  in  a  document. 

This  constituent  constraint  may  be  specified  as  a  subordinate  to  constituent  constraints  of  the  types: 

—  Paragraph; 

—  Title; 

—  ListTerm;  v 

—  Phrase; 

—  Caption; 

—  Description; 

—  FootnoteBody. 

It  is  a  composite  constituent  constraint  whose  immediate  sut)ordinates  may  consist  of  an  ordered 
sequence  of  constituent  constraints  of  the  types  BodyText,  ReferencedContent  and  BodyText. 

The  general  format  of  the  content  associated  with  a  constituent  constraint  of  the  type  Reference  Is: 

(<prefix-string>]<reference-string>[<suffix-string>] 

The  prefix  and  suffix  strings  are  optional  and,  if  required,  are  represented  by  constituent  constraints  of 
the  type  BodyText.  The  reference  string  is  represented  by  the  constituent  constraint. 
ReferencedContent. 

A  reference  string  may,  for  example,  contain  references  to  identifiers  such  as  a  number  that 
distinguishes  a  chapter  or  section,  a  table,  a  figure,  a  footnote,  an  item  in  a  numbered  list  or  a  page 
number   Each  reference  may  contain  multiple,  concatenated  references  to  different  parts  of  a 
document;  a  typical  example  is  the  reference  'see  table  3  in  chapter  2  on  page  4'  where  the  values  '3', 
'2'  and  '4'  are  derived  automatically  from  the  appropriate  table,  chapter  and  page  in  the  document. 
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6.2.3.10.2  ReferencedContent 


ReferencedContent  is  a  constituent  constraint  that  represents  a  character  string  that  contains  a  single 
reference  to  content  in  other  parts  of  the  document  (see  6.2.3.10.1). 

It  is  a  basic  logical  constituent  constraint  that  is  an  immediate  subordinate  to  the  constituent  constraint 
Reference.  It  contains  a  content  generator  which,  when  evaluated,  produces  the  character  string 
containing  the  referenced  content. 

A  sequence  of  two  or  more  constituent  constraints  of  this  type  may  be  used  to  represent  a  composite 
reference  string  such  as  see  table  2  in  section  3.1  beginning  on  page  6',  where  the  strings  '2',  "3.1'  and 
'6'  are  automatically  generated  by  referring  to  number  strings  attached  to  particular  parts  of  the 
document. 

The  format  of  this  content  generator  and  its  evaluation  is  described  in  6.6.7.9. 

Where  the  superior  constituent  constraint  referenced  is  subordinate  to  a  FootnoteBody,  it  is  required  to 
specify  one  of  the  layout  category  names  for  this  constituent  constraint.  Footnote'  or  'footnote-<n>'. 
This  along  with  a  permitted  categories  attribute  of  the  same  name  on  the  footnote  frame  will  ensure  that 
a  logical  object  from  this  constituent  constraint  is  laid  out  in  a  FootnoteArea  frame  when  generic  layout 
structure  is  specified  within  the  document. 

6.2.3.1 1  Constituents  representing  illustrations 


6.2.3.11.1  Introduction 

This  profile  supports  the  representation  of  illustrations  or  figures  consisting  of  artwori^  or  simple  forms. 

Artwork  typically  consists  of  a  diagram  or  figure  which  is  an  image  composed  of  a  single  content  type 
or  which  is  formed  by  overlaying  two  or  more  separate  images  consisting  of  character,  raster  graphics 
or  geometric  graphics  content. 

A  form  typically  consists  of  a  collection  of  logical  entities,  each  of  which  has  a  certain  logical 
significance.  Each  logical  entity  may  be  further  subdivided  into  subordinate  logical  entities.  A  typical 
example  is  an  order  form  consisting  of  a  reference  number,  information  about  the  originator,  Including 
the  name,  address  and  telephone  number,  a  list  of  items  required  and  their  expected  delivery  dates. 

The  entities  which  make  up  a  form  are  intended  to  be  laid  out  in  a  designated  area  which  is  sutxjivided 
into  areas  that  are  specially  reserved  for  each  particular  type  of  entity.  This  designated  area  is 
specified  by  the  frame  FormArea  when  the  generic  layout  structure  is  present  in  the  document. 

Optionally,  an  illustration  may  also  contain  an  identifier  which  may  be  used  to  distinguish  the  illustration 
from  other  parts  of  the  document,  a  caption  which  may  be  used  to  identify  the  purpose  of  the 
illustration,  and  an  amount  of  associated  descriptive  text. 

Further  information  concerning  the  layout  of  illustrations  consisting  of  artwork  or  forms  is  given  in 
6.4.1.3.7. 

The  constituent  constraints  used  to  represent  illustrations  are  defined  below. 
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6.2.3.11.2  Figure 


Figure  is  a  constituent  constraint  that  is  typically  used  to  represent  an  illustration.  Such  an  illustration 
may  consist  of  artwork  or  a  form  as  described  in  6.2.3.11.1. 

A  Figure  is  a  composite  logical  constituent  constraint  which  may  be  specified  as  a  sutK)rdinate  to  a 
Passage  or  NumberedSegment. 

The  subordinates  of  a  Figure  may  consist  of  a  sequence,  in  any  order,  of  the  following  constituent 
constraints: 

—  either  Artwoi1<  or  Form; 

—  Number; 

—  Caption; 

—  Description. 

A  constituent  constraint  of  the  type  Artwork  or  Form  must  always  be  present  as  a  sulx)rdinate  to  the 
constituent  constraint  Figure.  Constituent  constraints  of  the  types  Number,  Caption  and  Description  are 
independently  optional.  The  constituent  constraints  may  occur  in  any  order,  except  that  a  Numt)er  and 
a  Caption  shall  be  in  this  order. 


6.2.3.11.3  Artwork 

Artwork  is  a  constituent  constrain!  that  is  typically  used  to  represent  a  graphical  image  within  an 
illustration  or  figure.  This  may  be  a  simple  image  that  is  represented  by  character,  raster  graphics  or 
geometric  graphics  content,  or  it  may  be  a  composite  image  consisting  of  a  combination  of  these 
content  types. 

This  constituent  constraint  shall  only  occur  as  a  subordinate  to  a  constituent  constraint  of  the  type 
Figure. 

The  immediate  subordinates  of  Artwork  consist  of  an  arbitrary  ordered  sequence  of  one  or  more  of  the 
folk>wing  constituent  constraints: 

—  Phrase; 

—  BodyRaster; 

—  BodyGeometric. 

The  constituent  constraint  Phrase  is  used  to  enable  the  image  to  contain  character  content  which 
contains  references  to  footnotes  or  other  parts  of  the  document. 


6.2.3.11.4  Form 

Form  is  a  constituent  constraint  that  is  used  to  represent  a  simple  form  within  an  illustration  or  figure.  It 
is  a  composite  logical  constituent  constraint  which  shall  only  occur  as  a  sutx)rdinate  to  a  constituent 
constraint  of  the  type  Figure. 
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A  Form  consists  of  an  arbitrary  order  sequence  of  basic  entries  and  composite  entries.  Basic  entries, 
whicfi  may  consist  of  character,  raster  grapfiics  or  geometric  graphics  content,  are  represented  by 
sulDordinate  constituent  constraints  of  the  type  EntryElement.  Composite  entries  are  represented  by 
sut>ordinate  constituent  constraints  of  the  type  EntryGroup. 

Constituent  constraints  of  the  type  EntryGroup  may  be  further  subdivided  into  a  set  of  one  or  more 
basic  or  composite  entries.  Thus  a  composite  entry  may  be  nested  to  any  number  of  levels  such  that 
each  level  may  consist  of  a  set  of  subordinate  basic  and  composite  entries. 

This  profile  does  not  define  a  mechanism  for  defining  the  semantics  associated  with  each  basic  or 
composite  entry.  This  can  be  achieved  by  individual  applications  by  making  use  of  the  parameter 
"external  data"  in  the  attribute  "application  comments"  (see  6.6.5). 


6.2.3.11.5  Caption 

Caption  Is  a  constituent  constraint  that  typically  represents  a  title  or  header  that  is  associated  with  an 
Illustration  or  figure.  This  constituent  constraint  represents  character  content  that  may  contain 
embedded  references  to  footnotes  and  to  other  content  within  the  document. 

A  Caption  is  a  composite  logical  constituent  constraint  which  shall  only  occur  as  a  subordinate  to  a 
constituent  constraint  of  the  type  Figure. 

The  immediate  sutK)rdinates  of  a  Caption  consist  of  an  arbitrary  ordered  sequence  of  one  or  more  of 
the  following  constituent  constraints: 

—  BodyText; 

—  Reference; 

—  Phrase; 

—  Footnote. 

The  above  constituent  constraints  may  be  concatenated  to  form  a  continuous  stream  of  character 
content  which  is  to  be  laid  out  as  a  single  unit. 


6.2.3.11.6  Description 

Description  is  a  constituent  constraint  that  typically  represents  some  general  supplementary  information 
that  forms  part  of  an  illustration  that  contains  a  figure  or  form. 

This  constituent  constraint  is  a  composite  logical  constituent  constraint  which  shall  only  occur  as  a 
subordinate  to  a  constituent  constraint  of  the  type  Figure. 

The  immediate  subordinates  of  a  Description  consist  of  an  arbitrary  ordered  sequence  of  one  or  more 
of  the  following  constituent  constraints: 

—  BodyText; 

—  Reference; 

—  Phrase; 
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—  Footnote. 


The  atx)ve  constituent  constraints  may  be  concatenated  to  torm  a  continuous  stream  of  character 
content  which  is  to  be  laid  out  as  a  single  unit. 


6.2.3.11.7  EntryGroup 

Entn^Group  is  a  constituent  constraint  that  represents  a  composite  logical  entry  within  a  form. 

it  is  a  composite  logical  constituent  constraint  which  shall  only  occur  as  a  subordinate  to  a  constituent 
constraint  of  the  types  Form  or  EntryGroup. 

The  immediate  sutx)rdinates  of  a  EntryGroup  consist  of  an  arbitrary  ordered  sequence  of  one  or  nrore 
constituent  constraints  of  the  types  EntryElement  and  EntryGroup.  Therefore,  the  subordinates  to 
EntryGroup  may  be  nested  to  any  number  of  levels. 

NOTE  10  -  Constituent  constraint  EntryElement  Is  defined  in  6.2.3.12.6. 


6.2.3.12  Constituents  used  to  represent  tables 


6.2.3.12.1  Introduction  -  ;s 

For  the  purpose  of  this  profile,  a  table  is  a  logical  entity  that  consists  of  an  ordered  sequence  of 
elements,  called  cells",  that  are  arranged  into  a  two  dimensional  array  of  rows  and  columns. 

Each  row  may  consist  of  a  'simple'  row  which  contains  a  sequence  of  one  or  more  cells'.  Alternatively, 
a  row  may  consist  of  a  'composite'  row  which  contains  a  single  cell  followed  by  a  sequence  of  one  or 
more  subrows,  each  of  which  contains  a  sequence  of  cells'. 

The  sut)clauses  below  define  the  logical  constituents  used  to  represent  tables.  Figure  28  illustrates  the 
structural  relationships  between  the  constituents  used  to  represent  a  table.  Subclause  6.4.1 .3.8 
describes  how  tables  are  intended  to  be  laid  out. 


6.2.3.12.2  Table 

Table  is  a  logical  constituent  constraint  that  represents  a  table  as  a  whole.  This  constituent  constraint 
may  be  specified  as  a  subordinate  to  constituent  constraints  Passage  and  NumberedSegment. 

The  immediate  sutx)rdinates  of  this  constituent  constraint  consist  of  a  sequence  of  constituent 
constraints  Row.  Each  row  may  or  may  not  have  the  same  characteristics  with  regard  to  its  sub- 
stnjcture. 


6.2.3.12.3  Row 

Row  is  a  constituent  constraint  that  is  a  subordinate  of  the  constituent  constraint  Table  and  represents 
a  row  of  entries  in  a  table.  This  may  consist  of  a  sequence  of  entries,  or  it  may  consist  of  a  single 
entry  followed  by  a  sequence  of  subrows  of  entries. 

In  order  to  represent  these  two  cases,  the  immediate  subordinates  of  a  Row  may  consist  of  either: 
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—  a  sequence  of  constituent  constraints  EntryElement,  or; 

—  a  single  constituent  constraint  EntryElement,  followed  by  a  single  constituent  constraint 
of  the  type  TableComponent. 


6.2.3.12.4  TableComponent 

TableComponent  is  a  constituent  constraint  that  is  a  subordinate  of  the  constituent  constraint,  Row,  and 
represents  a  sequence  of  one  or  more  subrows  of  entries  within  a  row  of  a  table. 

The  immediate  sulx)rdinates  of  this  constituent  constraint  consist  of  a  sequence  of  one  or  more 
constituent  constraints  of  the  type  RowComponent.  Each  RowComponent  shall  have  the  same 
characteristics  with  regard  to  its  sub-structure. 


6.2.3.12.5  RowComponent 

RowComponent  is  a  constituent  constraint  that  is  a  subordinate  of  the  constituent  constraint 
TableComponent  and  represents  a  sub-row  of  entries  in  a  row  of  entries  in  a  table. 

The  immediate  subordinates  of  this  constituent  constraint  consist  of  a  sequence  of  one  or  more 
components  of  the  type  EntryElement.  Each  EntryElement  may  or  may  not  have  the  same 
characteristics  with  regard  to  its  sub-structure. 


6.2.3.12.6  EntryElement 

EntryElement  is  a  constituent  constraint  that  represents  a  single  entry  in  a  form  or  table.  It  is  a  sub- 
division of  constituent  constraints  of  the  types  Table  and  Form.  In  the  case  of  Table,  it  is  specified  as  a 
subordinate  to  a  Row  or  a  RowComponent  and  represents  a  single  entry  in  a  table.  In  the  case  of 
Form,  it  is  specified  as  a  sutx)rdinate  of  a  Form  itself  or  of  an  EntryGroup. 

Each  entry  in  a  table  or  form  may  consist  of  character,  raster  graphics  or  geometric  graphics  content 
and,  hence,  EntryElement  has  a  single  immediate  sulx)rdinate  constituent  constraint  of  the  type 
EntryText,  EntryRaster  or  EntryGeometric. 


6.2.3.12.7  EntryText,  EntryRaster  and  EntryGeometric 

EntryText.  EntryRaster  and  EntryGeometric  are  constituent  constraints  which  represent  content  that  is 
to  be  entered  into  tables  and  forms.  These  constituent  constraints  may  be  specified  as  subordinates  of 
the  constituent  constraint  EntryElement  and  allow  the  layout  and  presentation  requirements  for  the 
content  allocated  to  tables  and  forms  to  be  specified. 

These  are  basic  logical  constituent  constraints  that  directly  refer  to  content  portions  that  contain 
character,  raster  graphics  and  geometric  graphics  content  respectively.  EntryText  shall  refer  to  one  or 
more  content  portions  which  may  contain  either  processable,  formatted  or  formatted  processable 
character  content.  EntryRaster  and  EntryGeometric  shall  only  refer  to  a  single  content  portion 
containing  formatted  processable  raster  graphics  content  or  formatted  processable  geometric  graphics 
content  respectively. 

Constituent  constraints  of  these  types  in  the  generic  logical  structure  may  refer  to  generic  content.  This 
provides  the  means  of  defining  common  content  within  tables  and  forms. 
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6.2.3.13  Constituents  representing  lists 


6.2.3.13.1  introduction 

This  profile  supports  tiie  representation  of  tiiree  types  of  lists,  as  follows: 

—  numbered  lists  consisting  of  ordered  lists  of  items,  eacfi  of  whicfi  is  preceded  by  an 
identifier  such  as  an  alphabetic  character  or  numeral; 

—  unnumbered  lists  consisting  of  unordered  lists  of  items,  each  of  which  may  optionally  be 
preceded  by  a  separator  such  as  a  hyphen,  bullet  or  small  circle; 

—  definition  lists  consisting  of  lists  of  ordered  pairs  of  items  such  as  a  term  and  its 
corresponding  definition. 

Each  type  of  list  may  be  nested  without  restriction,  and  one  particular  type  of  list  may  be  composed  of 
lists  of  other  types.  For  example,  an  item  in  a  numbered  list  can  consist  of  a  subordinate  numbered 
list,  unnumbered  list  or  definition  list. 

The  constituent  constraints  that  may  be  used  to  represent  these  list  types  are  defined  below. 


6.2.3.13.2  NumberedLlst 

A  NumberedLlst  is  a  constituent  constraint  that  is  used  to  represent  a  list  of  items,  each  of  which  is 
preceded  by  an  identifier  that  serves  to  distinguish  that  item. 

This  constituent  constraint  may  be  specified  as  an  immediate  subordinate  to  a  Passage, 
NumberedSegment.  or  Listltem. 

The  immediate  subordinates  of  a  NumberedLlst  consist  of  the  constituent  constraint  Number  which 
contains  a  content  generator  that  generates  the  Identifier  corresponding  to  each  item  In  the  list,  followed 
by  the  constituent  constraint,  Listltem.  This  pair  of  constituent  constraints  may  be  repeated  without 
limitation. 

Further  Information  concerning  the  numbering  of  items  in  a  list  Is  contained  In  6.6.7.5. 


6.2.3.13.3  UnNumberedLlst 

UnNumberedLlst  is  a  constituent  constraint  that  is  used  to  represent  a  list  of  items,  each  of  which  may 
t>e  preceded  by  an  optional  separator  consisting  of  character,  raster  graphics  or  geometric  graphics 
content. 

This  constituent  constraint  may  be  specified  as  an  immediate  subordinate  to  a  Passage. 
NumberedSegment.  or  Listltem. 

The  Immediate  sutx)rdlnates  of  an  UnNumberedLlst  consist  of  a  separator,  which  Is  represented  by  a 
constituent  constraint  of  the  type  BodyText.  BodyRaster  or  BodyGeometrlc.  followed  by  the  constituent 
constraint  Listltem.  This  pair  of  constituent  constraints  may  be  repeated  without  limitation. 
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6.2.3.13.4  DefinitionList 


DefinitionList  is  a  constituent  constraint  that  represents  a  sequence  of  ordered  pairs  of  itenis. 

This  constituent  constraint  may  be  specified  as  an  immediate  sut>ordinate  to  a  Passage, 
NumberedSegment.  or  Listltem. 

The  immediate  sut)ordinates  of  this  item  consist  of  the  constituent  constraint  ListTerm,  followed  by  the 
constituent  constraint  Listltem.  This  pair  of  constituent  constraints  may  be  repeated  without  limitation. 


6.2.3.13.5  Listltem 

Listltem  is  a  constituent  constraint  that  represents  an  item  within  a  NumberedList.  UnNumt>eredList  or 
DefinitionList.  That  is,  this  constituent  constraint  represents  the  second  element  of  each  pair  of 
elements  within  a  numbered,  unnumbered  or  definition  list. 

The  immediate  sutwrdinates  of  this  constituent  constraint  may  consist  of  a  sequence  of  one  or  more 
constituent  constraints  Phrase,  or  one  of  the  constituent  constraints  NumberedList,  UnNumberedList  or 
DefinitionList. 

Thus  this  constituent  constraint  represents  an  amount  of  character  content  that  may  contain  embedded 
references  to  footnote  and  other  parts  of  the  document,  or  it  represents  a  subordinate  list  of  items. 


6.2.3.13.6  ListTerm 

ListTerm  is  a  constituent  constraint  that  represents  a  term  element  within  a  DefinitionList.  A  term 
element  is  the  first  item  of  each  pair  of  items  that  constitutes  a  definition  list. 

The  immediate  subordinates  of  this  constituent  constraint  consist  of  an  arbitrary  ordered  sequence  of 
one  or  more  of  the  following  constituent  constraints: 

—  BodyText; 

—  BodyRaster; 

—  BodyGeometric; 

—  Phrase; 

—  Reference, 

—  Footnote. 

Thus  this  constituent  constraint  represents  an  amount  of  character,  raster  graphics  and  geometric 
graphics  content.  Character  content  may  contain  embedded  phrases,  references  and  footnotes. 


6.2.4  Common  content  part  of  the  logical  structure 
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6.2.4.1  CommonContent 


CommonContent  is  a  constituent  constraint  that  represents  comrrron  content  that  is  laid  out  in  the  body, 
header,  or  footer  area  of  the  pages  of  a  document.  Common  content  consists  of  any  combination  of 
character,  raster  graphics  and  geometric  graphics  content. 

Any  number  of  constituent  constraints  CommonContent  may  be  contained  in  a  document. 
CommonContent  is  a  composite  logical  object  class  whose  immediate  subordinates  consist  of  an 
arbitrary  ordered  sequence  of  one  or  more  of  the  following  constituent  constraints: 


—  CommonText; 

—  CommonRaster; 

—  CommonGeometric; 

—  CommonReference; 

—  Currentlnstance; 

—  TableNumber; 

—  PageNumber; 

—  CommonNumber. 

When  the  generic  layout  structure  is  present,  constituent  constraints  of  the  type  CommonContent  and 
their  associated  subordinate  constituent  constraints  are  constrained  to  be  laid  out  in  a  specified  frame 
within  a  body,  header  or  footer  area  using  the  'logical  source'  mechanism  (see  6.3.6). 


6.2.4.2  CommonText 

CommonText  is  a  constituent  constraint  that  represents  the  common  character  content  that  is  to  be  laid 
out  in  a  specified  area  within  a  page. 

CommonText  is  a  constituent  constraint  for  a  basic  logical  object  class  that  references  one  or  more 
content  portions  each  containing  either  processable,  formatted  and  formatted  processable  character 
content. 


6.2.4.3  PageNumber 

PageNumber  is  a  constituent  constraint  that  represents  the  common  character  contejit  that  is  to  be  laid 
out  in  a  specified  area  in  a  page.  This  constituent  constraint  is  specifically  used  when  it  is  required  to 
represent  an  automatically  generated  page  number. 

PageNumber  is  a  basic  logical  object  class  that  contains  a  content  generator.  This  content  generator 
contains  a  reference  to  a  page  number  which  is  automatically  evaluated  when  the  document  is  laid  out. 
For  example,  this  provides  the  means  of  representing  the  page  numbers  that  are  displayed  on  the 
consecutive  pages  of  a  document. 
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Each  page  number  consists  of  a  single  number  which  may  be  represented  in  the  form  of  Arabic  or 
Roman  numerals  or  in  its  alphabetic  equivalent.  Page  numbering  schemes  may  start  at  0  or  any  value 
greater  than  0.  The  page  number  that  is  generated  may  have  a  prefix  or  suffix  character  string. 

The  format  of  the  content  generators  is  defined  in  6.6.7.8. 


6.2.4.4  CommonRaster 

CommonRaster  is  a  constituent  constraint  that  represents  the  common  raster  graphics  content  that  is  to 
be  laid  out  in  a  specified  area  within  a  page.  For  example,  this  constituent  constraint  may  be  used  to 
represent  a  logo  which  is  to  be  laid  out  on  each  page  of  a  document. 

Common  raster  is  a  constituent  constraint  for  a  basic  logical  object  class  which  references  a  single 
content  portion  containing  formatted  processable  raster  graphics  content. 


6.2.4.5  CommonGeometric 

CommonGeometric  is  a  constituent  constraint  that  represents  the  common  geometric  graphics  content 
that  is  to  be  laid  out  in  a  specified  area  within  a  page.  For  example,  this  constituent  constraint  may  be 
used  to  represent  a  graphical  icon  which  is  to  be  laid  out  on  each  page  of  a  document. 

CommonGeometric  is  a  constituent  constraint  for  a  basic  logical  object  class  which  references  a  single 
content  portion  containing  formatted  processable  geometric  graphics  content. 


6.2.4.6  CommonReference 

CommonReference  is  a  constituent  constraint  that  represents  the  common  character  content  that  is  to 
be  laid  out  in  a  specified  area  in  a  page  and  which  represents  a  character  string  that  contains 
references  to  other  parts  of  the  document.  Such  a  reference  may  consist  of  a  reference  to  a  number 
that  relates  to  a  segment,  table,  figure,  footnote  or  page  number. 

CommonReference  is  a  constituent  constraint  for  a  basic  logical  object  class  that  contains  a  content 
generator  which,  when  evaluated,  produces  a  character  string  containing  the  references.  The  format  of 
this  reference  string  is  defined  in  6.6.7.10. 


6.2.4.7  Currentlnstance 

Currentlnstance  is  a  constituent  constraint  that  represents  the  common  character  content  that  is  to  be 
laid  out  in  a  specified  area  in  a  page.  This  constituent  constraint  is  specifically  used  when  it  is  required 
to  refer  to  a  character  string  that  is  attached  to  any  logical  constituent  constraint  in  the  document  or  any 
of  the  layout  constituent  constraints  DocumentLayoutRoot,  PageSet,  RectoPage,  VersoPage  or  Page. 
The  number  string  may  represent,  for  example,  the  title  of  a  sub-section  or  table  that  is  contained 
elsewhere  in  the  document. 

Currentlnstance  is  a  constituent  constraint  for  a  basic  logical  object  class  that  contains  a  content 
generator  which,  when  evaluated,  produces  a  copy  of  the  character  string  associated  with  a  specified 
constituent.  The  format  of  this  reference  is  defined  in  6.6.7.1 1 . 
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6.2.4.8  TableNumber 


TableNumber  is  a  constituent  constraint  that  represents  the  common  character  content  that  is  to  be  laid 
out  in  a  specified  area  in  a  page.  This  constituent  constraint  is  specifically  used  when  it  is  required  to 
represent  a  table  number  which  is  to  be  placed  within  the  header  area  of  a  table. 

TableNumber  is  a  constituent  constraint  for  a  basic  logical  object  class  that  contains  a  content 
generator  which,  when  evaluated,  generates  the  required  table  number.  The  format  of  the  content 
generator  is  defined  in  6.6.7.6. 


6.2.4.9  CommonNumber 

CommonNumber  is  a  constituent  constraint  that  represents  the  common  character  content  that  is  to  be 
laid  out  in  a  specified  area  in  a  page.  This  constituent  constraint  is  specifically  used  when  it  is  required 
to  refer  to  character  content  consisting  of  a  number  string  which  can,  for  example,  represent  the 
number  of  a  sub-section  or  a  current  page. 

CommonNumber  is  a  constituent  constraint  for  a  basic  logical  object  class  that  contains  a  content 
generator  which,  when  evaluated,  generates  the  reference  to  the  required  number.  The  format  of  this 
reference  is  defined  in  6.6.7.12. 


6.3  Layout  characteristics 

This  sutx;lause  defines  the  layout  constituent  constraints  provided  by  this  profile  to  represent  the 
characteristics  of  documents. 

Different  constituent  constraints  may  be  used  to  represent  and  distinguish  parts  of  a  document  that 
have  different  layout  characteristics.  This  subclause  descrit>es  the  general  characteristics  and  typical 
uses  of  the  constituent  constraints  that  are  provided. 

The  descriptions  of  the  layout  characteristics  represented  by  each  of  the  constituent  constraints  is 
provided  for  guidance  only.  It  is  the  responsibility  of  the  user  to  determine  how  a  document  is  to  be 
represented  using  the  constituents  provided.  Adherence  to  these  guidelines  can  enhance  the  mutual 
understanding  of  a  document  by  an  originator  and  a  recipient. 


6.3.1  Overview  of  the  layout  characteristics 

The  document  structure  allows  the  document  content  to  be  laid  out  and  presented  in  one  or  more  page 
sets.  Each  page  set  may  be  used  for  different  parts  of  the  document,  for  example,  the  title  page, 
foreword,  table  of  contents,  document  txjdy  and  appendices. 

Each  page  set  consists  of  a  series  of  pages.  In  general,  each  page  may  be  sub-divided  into  three 
areas:  the  body  area,  which  is  used  to  layout  the  document  twdy;  and  the  header  and  footer  areas, 
which  may  be  used  to  layout  the  common  content. 

NOTE  11  -  In  the  case  of  FOD36,  common  content  may  also  be  laid  out  in  the  body  area,  as  well  as  the 
header/footer  area. 

Three  txDdy  layout  types  are  supported  by  this  profile.  Each  body  layout  type  specifies  how  the  lx)dy  is 
positioned  within  each  page,  and  how  the  content  may  be  presented  within  the  IXDdy.  These  are 
referred  to  as  body  layouts  A,  B,  and  C,  and  are  defined  in  6.3.4.5. 
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It  is  intended  that  all  applications  which  use  this  profile  shall  support  t>ody  layout  A,  whereas  support  for 
the  other  two  body  layouts  may  be  specified  as  optional. 

Body  layout  A  is  used  when  the  character  content  is  to  be  laid  out  horizontally  (from  left  to  right  or  from 
right  to  left)  and  from  top  to  t)Ottom  within  the  body  area.  This  layout  is  typically  used  for  contents 
written  in  Latin  based,  Hebrew,  Arabic,  and  Japanese  (most  cases)  languages. 

Body  layout  B  is  used  when  the  character  content  is  to  be  laid  out  vertically  (bottom  to  top  or  top  to 
bottom)  and  from  left  to  right  within  the  body  area.  This  layout  is  typically  used  for  contents  written  in 
Latin  based,  Hebrew,  Arabic,  and  Japanese  (most  cases)  languages  in  which  it  is  required  to  layout  the 
content  in  landscape  orientation  within  the  body  area  of  the  page. 

Body  layout  C  is  used  when  the  character  content  is  to  be  laid  out  vertically  and  from  right  to  left  within 
the  body  area.  This  layout  may  be  typically  used  for  contents  written  in  languages  which  use 
ideograms,  such  as  Japanese  and  Chinese  characters. 

The  t)ody,  header  and  footer  areas  may  be  further  sub-divided  into  areas  to  support  a  wide  range  of 
different  layout  requirements.  These  features  are  described  further  in  6.3.5  and  6.3.6. 


6.3.2  DocumentLayoutRoot 

DocumentLavoutRoot  is  a  constituent  constraint  that  represents  the  top  level  in  the  document  layout 
structure.  Its  immediate  subordinates  consist  of  a  sequence  of  one  or  more  constituent  constraints  of 
the  type,  PageSet.  The  numbering  schemes  for  pages  may  be  initialized  on  this  constituent  constraint. 


6.3.3  PageSet 

PageSet  is  a  constituent  constraint  that  represents  a  grouping  of  pages  within  a  document.  A  PageSet 
is  typically  used  to  represent  a  part  of  a  document  that  has  different  layout  requirements  from  other 
parts  of  a  document.  Also,  a  PageSet  may  correspond  to  a  part  of  a  document  that  has  a  certain 
logical  significance,  for  example,  a  PageSet  might  represent  the  front  matter  in  a  document  or  an 
individual  chapter. 

Only  one  level  of  PageSet  is  allowed  in  a  document.  However,  a  document  may  contain  any  number  of 
class  definitions  of  the  type  PageSet  which  may  be  used,  for  example,  to  provide  a  choice  of  alternative 
layouts  for  different  parts  of  a  document  or  to  specify  the  exact  layout  requirements  for  each  successive 
part  of  a  document. 

The  immediate  sutx)rdinates  of  a  PageSet  consist  of  a  combination  of  constituent  constraints  of  the 
types  Page,  RectoPage  and  VersoPage,  as  described  in  6.3.4.1 . 


6.3.4  Page  characteristics 


6.3.4.1  Page  constituents 

Three  constituent  constraints  are  provided  to  represent  the  pages  within  a  document,  namely  Page. 
RectoPage  and  VersoPage. 

The  pages  that  make  up  a  page  set  consist  of  an  artitrary  sequence  of  one  or  more  of  the  constituent 
constraints  Page,  RectoPage  and  VersoPage. 
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The  only  difference  in  the  characteristics  of  these  constituent  constraints  concerns  the  values  that  may 
be  specified  for  the  parameter  "side  of  sheet"  in  the  attribute  "medium  type".  In  the  case  of  Page,  the 
value  of  this  parameter  may  be  specified  as  "recto*,  verso'  or  unspecified".  In  the  case  of  RectoPage, 
the  value  of  this  parameter  may  be  specified  as  recto"  or  "unspecified";  in  the  case  of  VersoPage.  the 
value  of  this  parameter  may  be  specified  as  "verso'  or  "unspecified".  The  values. 'recto'  and  "verso",  of 
the  "side  of  sheet""  parameter  of  the  "medium  type"  attribute  are  non-basic. 

The  following  restrictions  also  apply  to  the  pages  within  a  page  set: 

a)  all  the  pages  shall  have  the  same  dimensions,  but  may  differ  in  orientation  (see 
6.3.4.2); 

b)  all  the  pages  are  to  be  laid  out  on  the  same  size  of  presentation  medium  (see  6.3.4.3); 

c)  all  the  pages  instantiated  from  a  given  page  class  shall  have  the  same  layout 
characteristics  (see  note).  That  is,  for  a  given  page  class,  there  is  not  a  choice  of 
layout  characteristics.  However,  the  layout  characteristics  of  pages  in  a  page  set  may 
or  may  not  be  the  same. 

NOTE  12  -  The  layout  characteristics  of  pages  are  specified  in  6.3.4.5.  Pages  having  the  same  layout 
characteristics  are  pages  for  which  the  body  area,  header  area  (it  present)  and  footer  area  (if  present)  have  the 
same  dimensions  and  position  within  the  page  (see  6.3.4.3).  However,  pages  having  the  same  layout 
characteristics  do  not  necessarily  have  the  same  position  on  the  presentation  medium  (see  6.3.4.4). 


6.3.4.2  Page  dimensions 

The  dimensions  of  the  pages  may  be  specified  as  any  value  (in  SMUs)  that  is  equivalent  to  or  less  than 
ISO  AO  or  ANSI  E  paper  sizes.  The  dimensions  may  be  specified  in  portrait  or  landscape  orientation. 
Japanese  page  sizes  B4  and  B5  are  also  supported,  but  the  dimension  of  these  pages  lie  within  the 
range  of  dimensions  given  at>ove. 

Dimensions  equivalent  to  or  less  than  the  common  assured  reproduction  area  of  ISO  A4  and  ANSI-A  in 
portrait  or  landscape  orientation  are  basic  values.  Larger  page  sizes  are  non-basic  and  their  use  shall 
be  indicated  in  the  document  profile. 

Any  default  page  dimensions  may  be  specified  in  the  document  profile  subject  to  the  maximum 
dimensions  defined  at)ove. 

NOTE  13  -  The  size  termed  "North  American  Letter  (NAL)'"  in  (CCITT  Recommendation  T.410  series  |  ISO 
8613]  (e.g.,  in  [CCITT  Recommendation  T.412  |  ISO  8613-2]  clause  7)  is  called  "ANSI-A"  in  this  specification  to 
be  consistent  with  the  other  reference  to  ANSI  standard  paper  sizes. 


6.3.4.3  Nominal  page  sizes 

The  nominal  page  sizes  that  may  be  specified  are  listed  in  table  1   These  may  be  specified  in  portrait 
or  landscape  orientation.  All  values  of  nominal  page  size  are  non-basic  and  hence  all  values  used  in  a 
document  shall  be  indicated  in  the  document  profile. 

Any  value  of  nominal  page  size  defined  in  table  1 ,  subject  to  the  restrictions  specified  above,  may  be 
specified  as  the  default  value  in  the  document  profile. 
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Table  1  also  includes  the  recommended  assured  reproduction  area  (ARA).  Information  loss  may  occur 
when  a  document  is  reproduced  if  the  dimensions  of  constituent  constraints  of  the  type  page  exceed 
the  ARA  for  the  specified  nominal  page  size. 


Table  1  —  Nominal  page  sizes 


Page  type 

Size  in  inches  or 
millimeters 

Size  in  BMUs 

ARA  in  BMUs 

ISO  A5 

148mm  x  210mm 

7015  X  9920 

not  defined 

ISO  A4 

210mm  X  297mm 

9920  X  14030 

9240  X  13200 

ISO  A3 

297mm  x  420mm 

14030  X  19840 

13200  X  18480 

ISO  A2 

420mm  x  594mm 

19840  X  28060 

18898  X  27118 

ISO  A1 

594mm  x  841mm 

28060  X  39680 

26173  X  37843 

ISO  AO 

841mm  x  1189mm 

39680  X  56120 

37843  X  54283 

ANSI  legal 

8.5in.  X  14in. 

10200  X  16800 

9240  X  1 5480 

ANSI  A 

8.5in.  X  11in. 

10200  X  13200 

9240  X  12400 

ANSI  B 

1  lin.  X  17in. 

13200  X  20400 

12744  X  19656 

ANSI  C 

17in.  X  22in. 

20400  X  26400 

19500  X  25800 

ANSI  D 

22in.  X  34in. 

26400  X  40800 

25800  X  39600 

ANSI  E 

34in.  X  44in. 

40800  X  52800 

39600  X  52200 

ANSI  F 

28in.  X  40in. 

33600  X  48000 

32400  X  47400 

Japan-legal 

257mm  x  364mm 

12141  X  17196 

1 1 200  X  1 5300 

Japan-letter 

182mm  x  257mm 

8598  X  12141 

7600  X 10200 

6.3.4.4  Page  offset 

The  page  offset  is  the  distance  of  the  position  of  the  left  and  top  edges  of  the  page  relative  to  the  left 
and  top  edges  respectively  of  the  presentation  medium  on  which  each  page  is  reproduced.  Any  value 
of  page  offset  may  be  specified  provided  that  no  part  of  the  page  area  lies  outside  the  area  of  the 
nominal  page.  Also,  page  offsets  specified  for  the  initial,  recto  and  verso  pages  within  a  given  page  set 
may  differ.  The  default  page  offset  may  be  specified  in  the  document  profile. 


6.3.4.5  Page  layout  characteristics 

Each  page  in  a  document  may  be  subdivided  into  three  rectangular  areas,  as  follows: 
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—  a  body  area,  which  is  reserved  for  content  that  t)elongs  to  the  body  part  of  the 
document  (see  6.3.5); 

—  a  header  area,  which  is  reserved  for  common  header  content  (see  6.3.6); 

—  a  footer  area,  which  is  reserved  for  common  footer  content  (see  6.3.6). 

The  body  area  is  mandatory  and  shall  occur  on  every  page  in  a  document.  The  header  and  footer 
areas  are  both  optional. 

Also  these  three  areas  shall  t>e  entirely  contained  within  the  page  area  and  must  not  overlap. 

Three  types  of  layout  of  twdy  area  are  defined: 

a)  Body  layout  type  A.  In  this  case,  the  layout  path  in  the  body  area  is  specrtied  as  270 
degrees. 

i    b)  Body  layout  type  B.  In  this  case,  the  layout  path  in  the  body  area  is  specified  as  0 
degrees. 

c)  Body  layout  type  C.  In  this  case,  the  layout  path  in  the  body  area  is  specified  as  180 
degrees. 

In  addition,  four  types  of  layout  of  header/footer  area  are  defined: 


a)  H/F  layout  A1 .  In  this  case,  the  layout  path  in  the  header  and  footer  area  is  270 
degrees.  If  the  header  or  footer  area  is  composite,  the  layout  paths  in  the  lowest 
frames  are  270  degrees; 

b)  H/F  layout  A2.  In  this  case,  the  layout  path  in  the  header  and  footer  area  is  0  degrees. 
If  the  header  or  footer  area  is  composite,  the  layout  paths  in  the  lowest  frames  are  270 
degrees; 

c)  H/F  layout  B1 .  In  this  case,  the  layout  path  in  the  header  and  footer  area  is  180 
degrees.  If  the  header  or  footer  area  is  composite,  the  layout  paths  in  the  lowest 
frames  are  180  degrees; 

d)  H/F  layout  B2.  In  this  case,  the  layout  path  in  the  header  and  footer  area  is  270 
degrees.  If  the  header  or  footer  area  is  composite,  the  layout  paths  in  the  lowest 
frames  are  180  degrees. 


Page  layout  type  is  determined  by  a  combination  of  the  body  layout  type  and  the  H/F  layout  type.  Any 
combination  is  permitted.  However,  it  is  intended  that  all  applications  which  use  this  profile  shall 
support  the  combinations  of  body  layout  A  and  H/F  layout  A1  and  A2,  whereas  support  for  other 
combinations  may  be  specified  as  optional. 

NOTE  14  -  The  combinations  of  body  layout  A  and  H/F  layout  A1,  B  and  A1,  C  and  A1,  and  C  and  81  are 
equivalent  to  page  layouts  A,  B,  C  and  D  in  FOD26  respectively. 

The  header  and  footer  of  H/F  layout  A1  or  A2  are  laid  out  above  and  below  the  body  area.  Figure  1 
illustrates  this  case,  and  figure2  illustrates  H/F  layout  type  A1  and  /\2  corresponding  to  this  case. 
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The  header  and  footer  of  H/F  layout  B1  or  B2  are  laid  out  to  the  right  arxl  left  of  the  body  area.  Figure 
3  illustrates  this  case,  and  figure  4  illustrates  H/F  layout  type  B1  and  82  corresponding  to  this  case. 
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Figure  1  —  Body  layout  types  A,  B  and  C  with  header  and  footer  above  and  below  the  body  area 
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Figure  2  —  Header  and  footer  frame  layouts  corresponding  to  Figure  1 
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Figure  3  —  Body  layout  types  A,  B  and  C  with  header  and  footer  to  the  right  and  left  of  the  tx)dy 
area 
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Figure  4  —  Header  and  footer  frame  layouts  corresponding  to  Figure  3 
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6.3.5  Body  area  characteristics 


6.3.5.1  General  characteristics 

The  body  area  is  the  area  within  a  page  where  the  main  matter  of  the  document,  that  is  the  'body'  part 
of  the  document,  is  laid  out.  The  layout  path  specified  in  the  body  area  determines  the  body  layout 
type  being  used. 

The  body  area  may  consist  of  a  single  frame  into  which  the  content  is  directly  laid  out.  In  this  case,  the 
body  area  is  represented  by  a  BasicBody  frame. 

Alternatively,  the  body  area  may  be  subdivided  into  different  rectangular  areas  to  provide  for  different 
layout  requirements.  In  this  case,  the  fc»ody  frame  is  represented  by  a  VariableCompositeBody  or 
FixedCompos'teBody  frame. 

The  subordinate  areas  within  a  VariableCompositeBody  frame  are  represented  by  variably  positioned 
frames.  Thus  the  subordinate  areas  are  not  pre-determined  and  are  automatically  adjusted  during  the 
layout  process  to  accommodate  the  content  that  is  allocated  to  them. 

When  a  FixedCompositeBody  frame  is  used,  the  subordinate  areas  are  represented  by  fixed  p)Ositioned 
frames,  and  hence  the  body  area  layout  can  be  precisely  specified. 

However,  in  order  to  provide  both  areas  whose  layout  is  fixed  and  areas  whose  layout  is  variable  within 
a  single  body  area,  it  is  possible  to  specify  one  or  more  VahableCompositeBody  frames  as 
subordinates  to  a  FixedCompositeBody  frame.  In  this  case,  the  layout  paths  for  each  of  the 
VariableCompositeBody  frames  may  or  may  not  be  the  same.  This  allows,  for  example,  text  belonging 
to  different  languages  to  be  laid  out  on  the  same  page. 


6.3.5.2  BasicBody 

BasicBody  is  a  constituent  constraint  which  defines  a  lowest  level  frame  which  represents  a  body  area 
into  which  content  is  directly  laid  out. 

The  position  and  dimensions  of  this  frame  are  fixed.  The  layout  path  specified  depends  upon  the  body 
layout  type  being  used  (see  6.3.4.5). 


6.3.5.3  VariableCompositeBody 

VariableCompositeBody  is  a  constituent  constraint  that  defines  a  composite  frame  which  represents 
either  the  entire  body  area  or  a  part  of  it,  and  which  contains  one  or  more  subordinate  variably 
positioned  frames.  A  VariableCompositeBody  frame  has  a  fixed  position  and  fixed  dimensions.  The 
layout  path  specified  for  this  frame  depends  upon  the  layout  type  used  (see  6.3.1). 

The  immediate  subordinates  of  this  frame  consist  of  an  arbitrary  ordered  sequence  of  one  or  more 
frames  of  the  following  constituent  constraints: 

—  BasicFloat; 

—  SnakingColumns; 

—  SynchronizedColumns; 
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—  CompositeFloat; 

—  CompositeFixture  Variable; 

—  Table  Area; 

—  Footnote  Area; 

—  ArrangedContentVariable; 

—  Sou  rcedContent  Variable. 

The  subordinate  frames  are  all  variably  positioned  and  have  variable  dimensions  except  for 
ArrangedContentVariable  frames.  Thus  the  relative  positions  of  these  frames  in  the  body  area  may 
vary  and  depend  upon  the  positions  of  other  frames  (if  any)  that  are  placed  in  the  same 
VariableCpmpositeBody  frame. 

The  layout  path  for  VariableCompositeBody  frames  may  be  specified  as  270,  0  or  180  degrees.  This 
determines  the  body  layout  type  used  in  the  case  where  VariableCompositeBody  represents  the  entire 
lx)dy  area  (see  6.3.4.5). 

All  immediate  subordinate  frames  are  laid  out  along  the  layout  path  specified  (in  normal'  positioning  fill 
order).  FootnoteArea  frames  are  laid  out  in  the  same  direction  as  the  body  area  layout  path,  but 
reverse  fill  order  is  used. 

Also  frames  are  constrained  to  have  the  same  layout  path  as  the  VariableCompositeBody  frame  to 
which  they  are  sutx)rdinate.  However,  exceptions  to  this  rule  are  frames  of  the  types 
CompositeFixtureVariable,  CompositeFloat,  SnakingColumns  and  SourcedContentVariable  (see 
appropriate  sutxiause  below). 

Figures  5,  6  and  7  provide  illustrations  of  the  layout  of  frames  within  a  VariableCompositeBody  frame 
for  the  various  tx)dy  layout  types. 

A  choice  of  sulx)rdinate  frames  of  the  types  listed  atx)ve  may  be  specified  for  a 
VariableCompositeBody  frame.  Different  frame  types  may  be  selected  using  various  layout  directives 
(see  6.4)  and,  therefore,  the  layout  characteristics  of  the  body  areas  within  a  page  set  may  change 
from  page  to  page  within  a  page  set. 


6.3.5.4  FixedCompositeBody 

FixedCompositeBodv  is  a  constituent  constraint  that  defines  a  composite  frame  which  represents  the 
tx)dy  area  and  which  contains  one  or  nx)re  sutwrdinate  frames  that  are  fixed  in  position.  The  position 
and  dimensions  of  this  frame  are  fixed. 

The  immediate  subordinates  of  frames  of  this  type  consist  of  an  artDitrary  ordered  sequence  of  one  or 
more  frames  of  the  following  constituent  constraints: 

—  BasicFixture; 

—  ColumnFixed; 

—  CompositeCommon; 

—  CompositeFixtureFixed; 
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Figure  5  —  Example  of  txxly  area  layout  for  body  layout  type  A 

—  ArrangedContentFixed; 
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Figure  6  —  Example  of  body  area  layout  for  body  layout  type  B 
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Figure  7  —  Example  of  body  area  layout  for  body  layout  type  C 
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—  SourcedContentFixed; 
. —  VariableCompositeBody. 
The  subordinate  frames  may  overlap  without  restriction. 

The  layout  path  for  FixedCompositeBody  frames  may  be  specified  as  270,  0  or  180  degrees.  This 
determines  the  body  layout  type  used  (see  6.3.4.5).  The  layout  path  specified  does  not  affect  the 
positioning  of  frames,  but  it  may  affect  their  dimensions  since  some  of  the  frames  listed  above  have 
variable  dimensions  in  a  particular  direction. 

Also  frames  are  constrained  to  have  the  same  layout  path  as  the  FixedCompositeBody  frame  to  which 
they  are  subordinate.  However,  exceptions  to  this  rule  are  frames  of  the  types  VariableCompositeBody, 
CompositeFixtureFixed  and  SourcedContentFixed  (see  appropriate  sulxlause  below). 

A  choice  of  sut)ordinate  frames  of  the  types  listed  above  may  be  specified  for  a  FixedCompositeBody 
frame.  Different  frame  types  may  be  selected  using  various  layout  directives  (see  6.4),  and,  therefore, 
the  layout  characteristics  of  the  kxjdy  areas  within  a  page  set  may  change  from  page  to  page  within  a 
page  set. 

6.3.5.5  BasicFloat 

BasicFloat  is  a  constituent  constraint  that  defines  a  lowest  level  frame  that  is  used  to  represent  a  single 
column  area  within  a  body  area. 

This  is  a  variably  positioned  frame  which  may  be  specified  as  a  subordinate  to  frames  of  the  types 
VariableCompositeBody.  CompositeColumn Variable,  CompositeColumnFixed,  CompositeFixtureVariable 
and  CompositeFixtureFixed. 

The  dimension  of  this  frame  in  the  direction  orthogonal  to  the  layout  path  of  the  body  area  is  fixed  or 
defaults  to  the  maximum  value  allowed  within  the  body  area. 

The  dimension  of  this  frame  in  the  direction  parallel  to  the  layout  path  of  the  body  area  is  specified  as 
'Rule-B'.  This  dimension  is  therefore  automatically  adjusted  during  the  layout  process  to  be  the 
minimum  required  to  contain  all  the  content  allocated  to  the  frame. 

The  layout  path  specified  for  this  frame  is  the  same  as  that  specified  for  its  superior  frame.  Content 
shall  only  be  laid  out  in  this  frame  in  the  direction  of  the  layout  path  specified. 


6.3.5.6  Snaking  Columns 

SnakingColumns  is  a  constituent  constraint  that  defines  a  composite  frame  that  represents  a  snaking 
columns  area  within  a  body  area.  A  snaking  columns  area  is  typically  used  for  the  layout  of  one  or 
more  columns  of  content  in  which  the  content  is  allowed  to  flow  freely  from  one  column  to  the  next. 
Examples  are  shown  in  figure  8  and  figure  9. 

This  is  a  variably  positioned  frame  which  may  only  be  specified  as  a  subordinate  to  a 
VariableCompositeBody  frame. 

Its  immediate  subordinates  consist  of  an  arbitrary  ordered  sequence  of  one  or  more  frames  of  the 
following  constituent  constraints: 
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Figure  8  —  Example  of  the  layout  of  a  snaking  columns  frame 
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Figure  9  —  Another  example  of  the  layout  of  a  snaking  columns  frame 


—  ColumnVariable; 

—  CompositeColumn  Variable; 

—  ArrangedContentVariable; 

—  SourcedContentVariable. 

The  dimension  of  the  SnakingColumns  frame  in  the  direction  orthogonal  to  the  layout  path  of  the  body 
area  is  fixed  or  defaults  to  the  maximum  value  allowed  within  the  body  area. 
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The  dimension  of  this  frame  in  the  direction  parallel  to  the  layout  path  of  the  body  area  is  specified  as 
■Rule-B".  This  dimension  is  therefore  automatically  adjusted  to  accommodate  the  subordinate  frames 
which  are  laid  out  in  it. 

The  layout  path  for  a  SnakingColumns  frame  may  be  specified  as  0  or  180  degrees  in  the  case  of  body 
layout  A,  90  or  270  degrees  in  the  case  of  body  layout  B,  and  270  degrees  in  the  case  of  body  layout 
C. 

The  attribute  "balance"  may  be  specified  for  a  SnakingColumns  frame  to  indicate  that  two  or  more  of 
the  sulx)rdinate  ColumnVariable  frames  are  to  be  approximately  equal  in  length  in  the  vertical 
dimension  in  the  case  of  body  layout  A  and  approximately  equal  in  length  in  the  horizontal  dimension  in 
the  cases  of  body  layouts  B  and  C.  Note  that  "approximately  equal"  in  the  context  of  the  "balance" 
attribute  means  that  the  leading  edges  of  the  layout  objects  being  balanced  are  aligned  as  closely  as 
possible  to  a  line  orthogonal  to  the  layout  path  for  the  objects. 


6.3.5.7  SynchronizedColumns 

SynchronizedColumns  is  a  constituent  constraint  that  defines  a  composite  frame  that  represents  a 
synchronized  columns  area  within  a  body  area.  A  synchronized  columns  area  is  typically  used  to 
represent  one  or  more  columns  of  content  such  that  the  content  laid  out  in  each  column  belongs  to 
different  layout  streams.  Thus  content  laid  out  in  one  column  is  not  allowed  to  flow  into  the  next 
column. 

This  type  of  column  layout  is  typically  used  when  It  Is  required  to  layout  separate  amounts  of  content  In 
parallel  with  one  another  such  that  they  are  aligned.  Examples  are  the  synchronized  layout  of  content 
belonging  to  different  languages  and  the  layout  of  a  figure  in  parallel  with  some  text.  An  example  is 
shown  in  figure  10. 

With  regard  to  positioning  and  dimensioning,  SynchronizedColumns  frames  have  the  same 
characteristics  as  SnakingColumns  frames. 

The  immediate  sulx)rdinates  of  a  SynchronizedColumns  frame  consist  of  an  arbitrary  ordered  sequence 
of  one  or  more  of  the  following  constituent  constraints: 

—  ColumnFixed; 

—  CompositeColumnFixed; 

—  ArrangedContentFixed; 

—  SourcedContentFixed. 

The  layout  path  for  a  SynchronizedColumns  frame  is  270  degrees  for  body  layout  A,  0  degrees  for 
body  layout  B  and  180  degrees  for  body  layout  C. 


6.3.5.8  ComposlteFloat 

CompositeFloat  Is  a  constituent  constraint  that  defines  a  composite  frame  that  specifies  an  area  which 
is  used  for  the  side  by  side  layout  of  complex  objects  such  as  figures,  forms  or  tables  and  simple 
columns  of  text. 

This  is  a  variably  positioned  frame  which  may  be  specified  as  a  subordinate  to  a 
VariableCompositeBody,  CompositeColumnVariable  or  CompositeColumnFixed  frame. 
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Figure  10  —  Example  of  the  layout  of  a  synchronized  column 


The  dimension  of  a  CompositeFloat  frame  in  the  direction  orthogonal  to  the  layout  path  of  its  superior 
frame  is  fixed  or  defaults  to  the  maximum  value  allowed. 

The  dimension  of  the  frame  in  the  direction  parallel  to  the  layout  path  is  specified  by  'Rule-A'.  Thus  the 
dimension  in  this  direction  is  determined  by  the  dimension  in  the  same  direction  of  the  first  frame  that  is 
laid  out  in  the  CompositeFloat  frame. 

The  immediate  subordinates  of  this  frame  consist  of  an  arbitrary  ordered  sequence  of  one  or  more  of 
the  following  constituent  constraints: 

—  BasicColumn; 

—  CompositeFixtureVahable; 

—  TableArea; 

—  ArrangedContentVariable; 

—  SourcedContentVariable. 

The  layout  path  for  a  CompositeFloat  may  be  specified  as  0  or  180  degrees  in  the  case  of  body  layout 
A  and  as  90  or  270  degrees  in  the  case  of  body  layouts  B  and  C. 

A  typical  example  of  the  use  of  this  constituent  is  a  form  or  an  illustration  with  character  content  flowing 
to  its  side  as  shown  in  figure  1 1 . 
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Figure  11  —  Example  of  a  CompositeFloat  frame 


6.3.5.9  CompositeFixtureVariable 

CompositeFixtureVariable  is  a  constituent  constraint  that  defines  a  composite  frame  used  to  specify  an 
area  which  is  used  to  layout  an  illustration,  such  as  a  figure  or  form,  with  which  is  associated  some 
descriptive  text  and  a  caption.  Hence,  the  prime  purpose  of  this  frame  is  to  layout  logical  constituent 
constraints  of  the  type  Figure. 

This  is  a  variably  positioned  frame  which  may  be  specified  as  a  sutwrdinate  to  a 
VariableCompositeBody,  CompositeColumn Variable  or  CompositeColumnFixed  frame. 

The  dimension  of  a  CompositeFixtureVariable  frame  in  the  direction  orthogonal  to  the  layout  path  of  the 
superior  frame  is  fixed,  specified  as  Rule-B'  or  defaults  to  the  maximum  allowed.  In  the  direction 
parallel  to  the  layout  path  of  the  superior  frame,  the  dimension  may  be  fixed  or  specified  as  'Rule-B". 

The  immediate  subordinates  of  this  frame  consist  of  an  arbitrary  ordered  sequence  of  one  or  more  of 
the  following  constituent  constraints: 

—  BasicFloat; 

—  CompositeArlwork; 

—  FormArea; 

—  FootnoteArea. 

NOTE  15  -  The  layout  path  of  a  CompositeFixtureVariable  frame  may  be  set  to  0,  180  or  270  degrees  in  the 
case  of  body  layout  A,  to  0,  90  or  270  degrees  in  the  case  of  body  layout  B  and  180  or  270  degrees  in  the 
case  of  body  layout  C. 


All  subordinate  frames  are  laid  out  in  'normal'  positioning  fill  order  with  the  exception  of  FootnoteArea 
frames  which  are  laid  out  in  reverse"  fill  order. 
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Examples  of  the  layout  of  CompositeFixtureVariable  frames  are  sfiown  in  figure  12. 
6.3.5.10  CompositeFixtureFixed 

CompositeFixtureFixed  is  a  constituent  cx)nstraint  that  defines  a  composite  frame  which  has  the  same 
characteristics  as  that  of  a  CompositeFixtureVariable  frame,  except  for  the  positioning  and  dimensions. 


This  frame  may  be  specified  as  a  subordinate  to  a  FixedCompositeBody  frame. 


6.3.5.11  CompositeArtwork 

CompositeArtwork  is  a  constituent  constraint  that  defines  a  composite  frame  that  represents  an  area 
that  contains  an  illustration  such  as  a  figure  or  diagram.  It  is  used  for  laying  out  logical  constituents  of 
the  type  Artwork  which  are  subordinate  to  logical  constituent  constraints  of  the  type  Figure. 

This  is  a  variably  positioned  frame  that  may  be  specified  as  a  subordinate  to  a 
CompositeFixtureVariable  or  CompositeFixtureFixed  frame. 

The  dimensions  of  this  frame  in  the  directions  orthogonal  and  parallel  to  the  layout  path  of  the  superior 
frame  may  be  independently  either  fixed  or  specified  as  "Rule-B". 

The  immediate  subordinates  of  a  CompositeArtwork  frame  consist  of  a  sequence  of  one  or  more  lowest 
level  frames  of  the  type  BasicFixture  which  contain  character,  raster  graphics  or  geometric  graphics 
content.  BasicFixture  frames  may  overtap  to  allow  composite  images  to  be  formed. 

The  layout  path  of  a  CompositeArtwork  frame  is  set  to  be  the  same  as  that  of  its  superior  frame  (see 
note). 

NOTE  16  -  Subject  to  this  restriction,  this  means  that  the  layout  path  of  a  CompositeArtwork  frame  may  be  set 
to  0,  180  or  270  degrees  in  the  case  of  body  layout  A,  to  0,  90  or  270  degrees  in  the  case  of  body  layout  B 
and  180  or  270  degrees  in  the  case  of  body  layout  C. 


6.3.5.12  BasicFixture 

BasicFixture  is  a  constituent  constraint  that  defines  a  lowest  level  frame  which  specifies  an  area  for 
laying  out  content  within  FixedCompositeBody  and  CompositeArtwork. 

This  frame  has  a  fixed  position  within  its  superior  frame.  The  dimensions  of  this  frame  in  the  directions 
orthogonal  and  parallel  to  the  layout  path  of  the  superior  frame  may  be  independently  either  fixed  or 
specified  as  'Rule-B'. 

If  the  superior  frame  of  a  BasicFixture  frame  is  FixedCompositeBody,  the  layout  path  of  the 
BasicFixture  frame  is  set  to  be  the  same  as  that  of  its  superior  frame. 

If  the  superior  frame  of  a  BasicFixture  frame  is  CompositeArtwort^,  the  layout  path  of  the  BasicFixture 
frame  is  restricted  as  follows: 


45 


Body   layout  type  A 


Compos  j  t^F  i  xtur^var  <  ata l e 


Bas  i  cF 1  oat 

Ccapt  i  on^ 

'  LP 

Compos  i  teArtwork 


Bas  i  cF 1  oat 

Cdescr  i  pt  i  ve  text]) 

'  LP 

Foot note Area 


I  ayout 
path 


Key  : 

CP  =  character  path 
LP  =   line  progression 


Figure  12  —  Example  of  a  CompositeFixture Variable  frame 
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—  if  the  layout  path  of  the  superbr  frame  is  set  to  270  degrees,  the  layout  path  of 
BasicFixture  may  be  set  to  270  or  180  degrees; 

—  if  the  layout  path  of  the  superior  frame  is  set  to  0  degrees,  the  layout  path  of 
BasicFixture  may  be  set  to  0  or  270  degrees; 

—  if  the  layout  path  of  the  superior  frame  is  set  to  180  degrees,  the  layout  path  of 
BasicFixture  may  be  set  to  180  or  270  degrees. 


6.3.5.13  FormArea 

FormArea  is  a  constituent  constraint  that  defines  a  composite  frame  which  represents  a  fixed 
dimensioned  area  reserved  for  laying  out  an  illustration  consisting  of  a  form. 

This  area  is  divided  into  one  or  more  simple'  and  composite'  areas.  A  simple  area  is  one  in  which 
content  is  directly  laid  out.  A  composite'  area  is  an  area  which  is  further  divided  into  one  or  more 
simple  and  composite  areas. 

This  is  a  variably  positioned  frame  that  may  be  specified  as  a  sutx)rdinate  to  a 
CompositeFixtureVariable  or  CompositeFixtureFixed  frame. 

The  dimensions  of  this  frame  are  fixed  in  both  directions. 

The  immediate  sutx)rdinates  of  a  FormArea  frame  consists  of  an  arbitrary  ordered  sequence  of  one  or 
more  fixed  positioned  frames  of  the  following  constituent  constraints: 

—  FormEntryArea; 

—  EntryGroupArea; 

—  ArrangedContentFixed. 

Frames  of  the  type  FormEntryArea  and  ArrangedContentFixed  represent  'simple'  areas  in  a  form  as 
described  above.  EntryGroupArea  frames  represent  'composite'  areas. 

The  layout  path  of  a  FormArea  frame  defaults  to  270  degrees  and  does  not  affect  the  layout  of 
sutKjrdinate  frames. 

An  example  of  the  layout  of  a  form  is  shown  in  Figure  13. 


6.3.5.14  EntryGroupArea 

EntryGroupArea  is  a  constituent  constraint  that  represents  a  composite  area  within  a  FormArea  frame. 
The  positions  and  dimensions  of  this  frame  are  fixed  in  both  directions.  The  layout  path  of  this  frame 
defaults  to  270  degrees. 

The  immediate  sut>ordinates  of  this  frame  consist  of  an  arbitrary  ordered  sequence  of  one  or  more  fixed 
positioned  frames  of  the  type  FormEntryArea. 
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6.3.5.15  FormEntryArea 

FormEntryArea  is  a  constituent  constraint  that  defines  a  lowest  level  frame  that  specifies  an  area  for 
laying  out  content  within  a  FormArea  frame.  This  frame  may  contain  character,  raster  graphics  or 
geometric  graphics  content. 


The  position  and  dimensions  of  this  frame  are  fixed.  Its  layout  path  is  270  degrees  regardless  of  the 
page  layout  type. 


6.3.5.16  BasicColumn 


BasicColumn  is  a  constituent  constraint  that  defines  a  lowest  level  frame  that  specifies  an  area  for 
laying  out  content  in  the  form  of  a  column  within  a  CompositeFloat  frame.  This  frame  has  a  variable 
position  within  its  superior  frame. 

The  dimension  of  this  frame  in  the  direction  orthogonal  to  the  layout  path  of  its  superior  frame  may  be 
fixed  or  specified  as  'Rule-B'.  Its  dimension  in  the  direction  parallel  to  the  layout  path  of  the  superior 
frame  may  be  fixed,  specified  as  'Rule-B'  or  defaulted  to  its  maximum  size.  Thus  the  dimensions  of 
this  frame  may  be  allowed  to  be  automatically  adjusted  so  that  it  contains  all  the  content  allocated  to  it 

The  layout  path  specified  for  this  frame  is  specified  as  270  degrees  in  the  case  of  body  layout  A,  0 
degrees  in  the  case  of  body  layout  B  and  180  degrees  in  the  case  of  body  layout  C. 
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6.3.5.17  ColumnVariable 


ColumnVariable  is  a  constituent  constraint  that  defines  a  lowest  level  frame  that  is  used  to  represents  a 
column  of  content  within  a  SnakingColumns  frame.  This  is  a  frame  which  is  variably  positioned. 

The  dimension  of  this  frame  in  the  direction  parallel  to  the  layout  path  of  the  superior  SnakingColumns 
frame  (that  is,  the  column  width)  is  fixed.  The  dimensions  of  different  instances  of  ColumnVariable 
frames  within  a  given  SnakingColumns  frame  may  differ  to  allow  columns  of  different  widths  to  be 
specified. 

The  dimension  in  the  direction  orthogonal  to  the  layout  path  of  the  superior  frame  (that  is,  the  column 
length)  may  be  specified  as  'Rule-B'  or  "maximum-size". 

The  layout  path  for  ColumnVariable  frames  is  270  degrees  in  the  case  of  t)ody  layout  A,  0  degrees  in 
body  layout  B  and  180  degrees  in  body  layout  C. 

All  ColumnVariable  frames  subordinate  to  the  same  SnakingColumns  frame  shall  have  the  same 
category  name;  different  names  may  be  used  for  ColumnVariable  frames  laid  out  in  different 
SnakingColumns  frames. 


6.3.5.18  CompositeColumnVariable 

CompositeColumnVariable  is  a  constituent  constraint  that  defines  a  composite  frame  which  specifies  an 
area  representing  a  column  within  a  SnakingColumns  frame.  The  column  is  subdivided  into  different 
areas  to  allow  different  layout  requirements  to  be  achieved.  For  example,  this  frame  can  be  used  to 
represent  a  column  containing  a  table  and  a  complex  diagram  which  is  embedded  in  a  stream  of 
character  content.  This  is  a  frame  which  is  variably  positioned. 

The  dimension  of  this  frame  in  the  direction  parallel  to  the  layout  path  of  the  superior  SnakingColumns 
frame  (that  is,  the  column  width)  is  fixed.  The  dimensions  of  different  instances  of 
CompositeColumnVariable  frames  within  a  given  SnakingColumns  frame  may  differ  to  allow  columns  of 
different  widths  to  be  specified. 

The  dimension  in  the  direction  orthogonal  to  the  layout  path  of  the  superior  frame  (that  is,  the  column 
length)  may  be  specified  as  "Rule-B"  or  'maximum-size'. 

The  immediate  subordinates  of  this  frame  consist  of  an  arbitrary  ordered  sequence  of  frames  of  the 
following  constituent  constraints; 

—  BasicFloat; 

—  Composite  Float; 

—  CompositeFixtureVariable; 

—  Table  Area; 

—  Footnote  Area; 

—  ArrangedContentVariable; 

—  SourcedContentVariable. 
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The  layout  path  tor  CompositeColumnVariable  trames  is  270  degrees  in  the  case  ot  txtdy  layout  A,  0 
degrees  in  body  layout  B  and  180  degrees  in  body  layout  C. 

All  subordinate  frames  are  laid  out  in  'normar  positioning  fill  order  except  FootnoteArea  which  is  laid  out 
in  'reverse'  fill  order. 


6.3.5.19  ColumnFixed 

ColumnFixed  is  a  constituent  constraint  that  defines  a  lowest  level  frame  that  is  used  to  represent  a 
column  of  content  within  a  FixedCompositeBody  or  SynchronizedColumns  frame.  This  is  a  frame  which 
has  a  fixed  position. 

The  dimension  of  this  frame  in  the  direction  orthogonal  to  the  layout  path  of  the  superior  frame  (that  is, 
the  column  width)  may  be  fixed  or  specified  as  maximum  size'  (see  note).  This  dimension  may  differ 
for  different  instances  of  ColumnFixed  frames  within  a  given  SynchronizedColumns  frame  to  allow 
columns  of  different  widths  to  be  specified.  However,  the  widths  shall  be  specified  such  that  the 
columns  do  not  overlap. 

The  dimension  of  this  frame  in  the  direction  parallel  to  the  layout  path  of  the  superior  frame  (that  is,  the 
column  length)  may  be  specified  as  'Pule-B'  or  'maximum-size'  in  the  cases  of  body  layouts  A  and  B. 
In  the  case  of  body  layout  C,  this  dimension  shall  only  be  specified  as  'maximum-size'. 

The  ColumnFixed  frames  sutx)rdinate  to  a  given  SynchronizedColumns  frame  must  have  different 
category  names. 

The  layout  path  for  ColumnFixed  frames  shall  be  equal  to  the  layout  path  of  the  superior 
SynchronizedColumns  frame. 

The  content  laid  out  in  different  ColumnFixed  frames  within  the  same  SynchronizedColumns  frame  may 
be  specified  as  synchronized'  by  using  the  attribute  "synchronization". 

NOTE  17  -  The  value  'maximum  size'  shall  only  be  specified  for  the  last  ColumnFixed  frame  laid  out  in  a 
SynchronizedColumns  frame  to  prevent  overlapping  of  the  frames.  That  is,  for  a  page  coordinate  system  with 
its  reference  point  in  the  upper  left  corner,  only  the  right  most  ColumnFixed  frame  shall  specify  maximum  size' 
without  the  risk  of  overlapping  frames. 


6.3.5.20  CompositeColumnFixed 

CompositeColumnFixed  is  a  constituent  constraint  that  defines  a  composite  frame  which  specifies  an 
area  representing  a  column  within  a  SynchronizedColumns  frame.  The  column  is  subdivided  into 
different  areas  to  allow  different  layout  requirements  to  be  achieved. 

The  characteristics  of  this  frame  are  the  same  as  those  of  CompositeColumnVariable  frames,  except 
that  this  frame  has  a  fixed  position,  and  its  dimensions  are  the  same  as  for  ColumnFixed  frames. 


6.3.5.21  FootnoteArea 

FootnoteArea  is  a  constituent  constraint  that  defines  a  lowest  level  frame  that  is  used  to  represent  an 
area  reserved  for  the  layout  of  footnotes.  Footnotes  may  be  placed  in  body  areas  and  also  in  columns 
and  areas  reserved  for  illustrations  within  body  areas. 

This  frame  may  be  specified  as  a  subordinate  to  frames  of  the  constituent  constraints; 
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—  VariableCompositeBody; 

—  CompositeColumn  Variable; 

—  CompositeColumnFixed; 

—  CompositeFixtureVariable; 

—  CompositeFixtureFixed. 

Frames  of  this  type  are  variably  positioned  with  a  positioning  fill  order  specified  as  reverse".  Therefore, 
this  frame  is  positioned  adjacent  to  the  leading  edge  of  its  superior  frame. 

The  dimension  of  FootnoteArea  frames  in  the  direction  orthogonal  to  the  layout  path  of  its  superior 
frame  is  fixed  or  specified  as  maximum  size'.  In  the  direction  of  the  layout  path,  the  dimension  is 
specified  by  'Rule-B'  which  means  that  this  dimension  is  automatically  adjusted  to  contain  all  the 
content  that  is  allocated  to  it. 

The  layout  path  for  FootnoteArea  frames  is  the  same  as  that  specified  for  the  superior  frame. 

The  content  that  may  be  laid  out  in  this  frame  is  limited  to  the  content  that  is  associated  with  basic 
logical  objects  which  are  directly  or  indirectly  subordinate  to  the  composite  logical  object  FootnoteBody. 
To  achieve  this,  the  "permitted  categories"  attribute  of  this  frame  shall  specify  the  same  category  name 
required  on  the  basic  logical  objects  for  footnotes  (see  6.2.3.9.4  and  6.2.3.9.5). 


6.3.5.22  CompositeCommon 

CompositeCommon  is  a  constituent  constraint  that  defines  a  composite  frame  which  specifies  an  area 
within  the  body  area  that  is  to  contain  common  content.  This  area  may  be  subdivided  so  that  different 
types  of  common  content  may  be  laid  out. 

This  Is  a  frame  which  has  fixed  positions  and  dimensions.  It  may  be  specified  as  a  subordinate  to  a 
FixedCompositeBody  frame. 

The  subordinates  of  a  CompositeCommon  frame  may  consist  of  either: 

a)  any  number  and  combination  of  variably  positioned  frames  of  the  types 
SourcedContentVariable  and  ArrangedContentVariable,  or; 

b)  any  number  and  combination  of  fixed  positioned  frames  of  the  types 
SourcedContentFixed  and  ArrangedContentFixed. 

In  case  b),  the  sut)ordinate  frames  may  overlap  without  restriction. 

The  layout  path  of  a  CompositeCommon  frame  is  270,  0  and  180  degrees  in  the  cases  of  tx)dy  layouts 
A,  B  and  C  respectively. 


6.3.5.23  Constituents  used  for  laying  out  tables 

This  subclause  defines  the  constituents  used  to  support  the  layout  of  tables.  An  overview  of  the  layout 
features  pertaining  to  tables  is  given  in  6.3.5.22.1  and  the  subsequent  sulxlauses  define  the  individual 
constituents  provided. 
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6.3.5.23.1  Overview 

A  table  consists  of  three  main  areas: 

—  a  single  optional  header  area  which  is  placed  at  the  top  of  the  table; 

—  a  single  optional  table  label  area  which  is  placed  immediately  below  the  header  area; 

—  one  or  more  row  areas,  which  are  placed  in  sequence  below  the  header  area  and  table 
label  area. 

The  table  header  area  is  typically  used  to  contain  a  title  or  caption  that  descrlt>es  the  purpose  of  the 
table.  It  is  an  area  which  is  subdivided  into  one  or  more  areas,  each  of  which  contains  comnwn 
content  derived  from  the  togical  structure  using  the  'logical  source'  mechanism. 

The  table  label  area  is  typically  used  to  contain  the  labels  which  relate  to  the  columns  in  the  table.  The 
row  areas  form  the  main  tx)dy  of  the  table  and  are  used  to  layout  the  information  that  belongs  to  the 
table.  These  areas  may  be  simple'  or  'composite'  as  described  below. 

An  example  of  a  simple  table  is  shown  in  figure  14.  In  this  example,  the  table  label  and  each  row 
consist  of  a  sequence  of  areas  called  cells'  which  are  laid  out  horizontally  across  the  table  area. 
These  are  examples  of  'simple'  table  label  and  row  areas. 


Table  header  area 

Table   label  area 

Row  area 

Row  area 

Row  area 

Row  area 

Row  area 


Figure  14  —  Example  of  a  simple  table 


An  example  of  a  more  complex  table  is  shown  in  figure  15  which  illustrates  the  use  of  'composite'  table 
labels  and  row  areas.  A  composite  table  label  area  consists  of  a  sequence  of  two  or  more  sub-rows, 
each  of  which  is  divided  into  separate  cells.  The  cells  in  each  row  may  or  may  not  be  the  same  size  to 
allow  a  label  to  refer  to  a  single  column  or  several  columns.   The  sequence  of  sub-rows  may  be 
preceded  on  the  left  by  a  single  cell  which,  for  example,  can  be  used  to  contain  a  title  which  refers  to 
the  group  of  sub-rows. 
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Figure  15  —  Example  of  a  complex  table 


Composite  row  areas  have  the  same  general  structure  as  composite  table  label  areas.  By  mixing 
together  different  combination  of  simple'  and  composite'  table  label  and  row  areas,  it  is  possible  to 
obtain  a  wide  range  of  different  table  types. 

The  frames  that  are  used  to  represent  table  label  and  row  areas  are  shown  in  figures  16  and  17 
respectively.  The  areas  labelled  as  cells'  are  intended  to  accomnrwdate  content  belonging  to  a  single 
content  type.  The  frames  which  represent  the  cells'  are  fixed  in  position  and  have  a  fixed  horizontal 
dimension.  However,  the  vertical  dimension  of  a  cell  may  be  specified  as  variable,  so  that  this 
dimension  is  automatically  adjusted  during  the  layout  process  to  accommodate  all  the  content  allocated 
to  it. 

In  the  case  of  a  composite  table  label  or  row,  the  containing  frame  (that  is,  the  LabelComponent  or 
SubRow  frame  respectively)  also  has  a  dimension  which  is  vahable  in  the  vertical  direction.  Thus  the 
dimension  of  this  frame  may  be  automatically  adjusted  during  the  layout  process  so  that  it  is  large 
enough  to  accommodate  the  largest  cell  in  that  row. 

Also,  the  containing  frames  (that  is,  the  CompositeTableLabel,  TableLabel,  SubRowGroup  and  SubRow 
frames)  may  all  be  specified  as  having  a  variable  vertical  dimension,  and,  therefore,  the  vertical 
dimension  of  each  table  label  and  row  area  may  be  automatically  adjusted  to  take  into  account  all  the 
information  that  is  to  be  laid  out  in  these  areas. 

The  frames  which  specifies  the  complete  table  area  (that  is,  the  TableArea  frame),  which  is  not  shown 
In  the  figures,  also  may  have  a  variable  vertical  dimension. 

The  mechanism  by  which  content  is  allocated  to  the  cells'  in  a  table  is  described  in  6.4.1.3.8. 
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6.3.5.23.2  TableArea 


TableArea  is  a  constituent  constraint  that  defines  a  composite  frame  ttiat  is  used  to  specify  an  area 
reserved  for  the  layout  of  a  table.  This  constituent  constraint  may  be  specified  as  a  subordinate  to  the 
following  constituent  constraints: 

—  VariableCompositeBody; 

—  CompositeFloat; 

—  CompositeColumn  Variable; 

—  CompositeColumnFixed. 

This  is  a  frame  that  has  a  variable  position.  Its  dimension  in  the  direction  orthogonal  to  the  layout  path 
of  the  superior  frame  is  fixed.  Its  dimension  in  the  direction  parallel  to  the  layout  path  is  fixed  or 
specified  as  'Rule-B'.  Its  layout  path  is  specified  as  270  degrees. 

The  immediate  subordinates  of  this  constituent  constraint  consist  of  an  optional  TableHeader,  followed 
by  an  optional  TableLabel,  which  is  followed  by  a  sequence  of  one  or  more  constituent  constraints  of 
the  types  RowArea  and  an  optional  TableLabel. 


6.3.5.23.3  TableHeader 

TableHeader  is  a  constituent  constraint  that  specifies  a  composite  frame  that  specifies  an  area  within  a 
TableArea  frame  that  is  typically  used  to  present  the  header  information  associated  with  a  table. 

This  is  a  frame  whose  position  is  variable   Its  dimension  in  the  direction  orthogonal  to  the  layout  path 
of  the  superior  frame  is  fixed.  Its  dimension  in  the  direction  parallel  to  the  layout  path  is  fixed  or 
specified  as  'Rule-B'. 

The  immediate  subordinates  of  this  constituent  constraint  consist  of  a  sequence  of  constituent 
constraints  of  the  type  SourcedContentFixed.  Hence,  the  content  laid  out  in  a  TableHeader  frame  is 
derived  from  logical  constituent  constraints  of  the  type  CommonContent. 


6.3.5.23.4  TableLabel 

TableLabel  is  a  constituent  constraint  that  defines  a  composite  frame  that  specifies  an  area  within  a 
TableArea  frame  that  is  used  for  laying  out  labelling  information  relating  to  the  columns  of  information  in 
the  table. 

This  is  a  frame  whose  position  is  variable   Its  dimension  in  the  direction  orthogonal  to  the  layout  path 
of  the  superior  frame  is  fixed.  Its  dimension  in  the  direction  parallel  to  the  layout  path  is  fixed  or 
specified  as  'Rule-B'. 

The  immediate  sutx)rdinates  of  this  constituent  constraint  consist  of  either: 

a)  a  sequence  of  one  or  more  constituent  constraints  of  the  type  TableLabelContent,  or; 

b)  a  sequence  of  a  constituent  constraint  of  the  type  TableLabelContent,  and  a  constituent 
constraint  of  the  type  Co mpositeTable Label. 
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Figure  16  —  Frames  used  to  represent  table  labels 


6.3.5.23.5  CompositeTableLabel 

CompositeTableLabel  is  a  constituent  constraint  that  defines  a  composite  frame  that  specifies  an  area 
with  a  TableLabel  frame  for  laying  out  a  composite  table  label. 

this  is  a  frame  whose  position  is  fixed.  Its  dimension  in  the  direction  orthogonal  to  the  layout  path  of 
its  superior  frame  is  fixed.  Its  dimension  in  the  direction  parallel  to  the  layout  path  is  fixed,  specified  as 
'Rule-B'  or  defaults  to  the  maximum  size  allowed. 

The  immediate  subordinates  of  this  constituent  constraint  consist  of  a  sequence  of  one  or  more 
constituent  constraints  of  the  type  LabelComponent. 


6.3.5.23.6  LabelComponent 

LabelComponent  is  a  constituent  constraint  that  defines  a  composite  frame  that  specifies  an  area  within 
an  CompositeTableLabel  frame  for  laying  out  a  row  of  labels  within  a  table  header. 

This  is  a  frame  whose  position  is  variable.  Its  dimension  in  the  direction  orthogonal  to  the  layout  path 
of  the  superior  frame  is  fixed.  Its  dimension  in  the  direction  parallel  to  the  layout  path  is  fixed,  specified 
as  'Rule-B'  or  defaults  to  the  maximum  size  allowed. 
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Figure  17  —  Frames  used  to  represent  table  rows 


The  immediate  sutx)rdinates  of  this  frame  consist  of  a  sequence  of  constituent  constraints  of  the  type 
TableLat)elContent. 


6.3.5.23.7  TableLabelContent 

TabteLabelContent  is  a  constituent  constraint  that  defines  a  lowest  level  frame  that  defines  an  area 
within  a  TableLabel  or  LabelComponent  frame  that  is  used  for  laying  out  header  information  that  relates 
to  one  or  n(X)re  columns  in  a  table.  Character,  raster  graphics  or  geometric  graphics  content  may  be 
allocated  to  this  frante. 

This  is  a  frame  whose  position  is  fixed.  Its  dimension  in  the  direction  orthogonal  to  the  layout  path  of 
the  superior  frame  is  fixed.  Its  dimension  in  the  directbn  parallel  to  the  layout  path  is  fixed  or  defaults 
to  the  maximum  size  allowed. 

The  content  of  a  frame  of  this  type  is  derived  from  a  logical  constituent  constraint  of  the  type 
CommonContent,  using  the  logical  source  mechanism. 
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6.3.5.23.8  RowArea 


Row  Area  is  a  constituent  constraint  that  defines  a  composite  frame  that  specifies  an  area  within  a 
Table  Area  frame  used  for  laying  out  a  row  of  entries  in  a  table. 

This  is  a  frame  whose  position  is  variable.  Its  dimension  in  the  direction  orthogonal  to  the  layout  path 
of  the  superior  frame  is  fixed.  Its  dimension  in  the  direction  parallel  to  the  layout  path  is  fixed  or 
specified  as  Rule-B". 

The  immediate  subordinates  of  this  constituent  constraint  consist  of  either: 

a)  a  sequence  of  one  or  more  constituent  constraints  of  the  type  Cell,  or; 

b)  a  sequence  of  a  single  constituent  constraint  of  the  type  Cell,  and  a  constituent 
constraint  of  the  type  SubRowGroup. 


6.3.5.23.9  SubRowGroup 

SubRowGroup  is  a  constituent  constraint  that  defines  a  composite  frame  that  specifies  an  area  within  a 
RowArea  frame  for  laying  out  a  composite  row  of  entries  in  a  table. 

This  is  a  frame  whose  position  is  fixed.  Its  dimension  in  the  direction  orthogonal  to  the  layout  path  of 
its  superior  frame  is  fixed.  Its  dimension  in  the  direction  parallel  to  the  direction  of  the  layout  path  is 
fixed,  specified  as  Rule-B'  or  defaults  to  the  maximum  size  allowed. 

The  immediate  sut)ordinates  of  this  constituent  constraint  consist  of  a  sequence  of  one  or  more 
constituent  constraints  of  the  type  SubRow. 


6.3.5.23.10  SubRow 

SubRow  is  a  constituent  constraint  that  defines  a  composite  frame  that  specifies  an  area  within  a 
SubRowGroup  frame  for  laying  out  a  sub  row  of  entries  within  a  composite  row  in  a  table. 

This  is  a  frame  whose  position  is  variable.  Its  dimension  in  the  direction  orthogonal  to  the  layout  path 
of  the  superior  frame  is  fixed.  Its  dimension  in  the  direction  parallel  to  the  layout  path  is  fixed,  specified 
as  Rule-B'  or  defaults  to  the  maximum  size  allowed. 

The  immediate  subordinates  of  this  frame  consist  of  a  sequence  of  constituent  constraints  of  the  type 
Cell. 


6.3.5.23.11  Cell 

Cell  is  a  constituent  constraint  that  defines  a  lowest  level  frame  that  specifies  an  area  within  a  RowArea 
or  SubRow  frame  for  laying  out  an  entry  in  a  table. 

This  is  a  frame  whose  position  is  fixed.  Its  dimension  in  the  direction  orthogonal  to  the  layout  path  of 
the  superior  frame  is  fixed.  Its  dimension  in  the  direction  parallel  to  the  layout  path  is  fixed,  specified 
as  'Rule-B'  or  defaults  to  the  maximum  size  allowed. 

The  content  of  frames  of  this  type  is  derived  from  logical  constituent  constraints  of  the  type 
EntryElement. 


57 


6.3.6  Header  and  footer  area  characteristics 


6.3.6.1  General  characteristics 

The  header  and  footer  areas  may  consist  of  either  basic  areas  or  composite  areas. 

A  basic  header  or  footer  area  is  an  area  into  which  the  content  is  directly  laid  out.  This  type  of  area  is 
represented  by  a  constituent  constraint  of  the  types  BasicHeader  or  BasicFooter  respectively. 

A  composite  header  or  footer  area  is  an  area  which  is  subdivided  into  separate  sourced  content  and 
arranged  content  areas  to  provide  greater  versatility  with  regard  to  the  layout  of  the  content.   This  type 
of  area  is  represented  by  a  constituent  constraint  of  the  types  CompositeHeader  or  CompositeFooter 
respectively. 

In  the  case  of  basic  header  or  footer  areas,  the  content  allocated  to  these  areas  is  derived  from  the 
common  part  of  the  logical  structure  of  a  document   In  the  case  of  composite  header  or  footer  areas, 
the  content  may  again  be  derived  from  the  common  part  of  the  logical  structure  of  a  document,  but  the 
content  may  also  be  derived  from  common  content  specified  in  the  generic  layout  structure. 


6.3.6.2  BasicHeader  and  BasicFooter 

BasicHeader  and  BasicFooter  are  constituent  constraints  that  define  lowest  level  franies  that  represent 
areas  within  a  page  that  are  reserved  for  common  content 

These  types  of  frame  have  fixed  positions  and  dimensions  The  positioning  of  these  frames  within  a 
page  and  the  layout  paths  that  may  be  specified  for  them  depends  upon  the  H/F  layout  type  used  (see 
6.3.4.5). 

The  content  that  is  laid  out  in  these  frames  is  derived,  using  the  logical  source  mechanism,  from  the 
content  associated  with  the  composite  logical  object  classes  of  the  type  CommonContent. 


6.3.6.3  CompositeHeader  and  CompositeFooter 

CompositeHeader  and  CompositeFooter  are  constituent  constraints  that  define  composite  frames  that 
represent  areas  within  a  page  that  are  reserved  for  common  content. 

These  types  of  frame  have  fixed  positions  and  dimensions.  The  positioning  of  these  frames  within  a 
page  and  the  layout  paths  that  may  be  specified  for  them  depends  upon  the  H/F  layout  type  used  (see 
6.3.4.5) 

The  subordinates  of  these  frames  may  consist  of  either: 

a)  any  number  and  combination  of  variably  positioned  frames  of  the  types 
SourcedContentVariable  and  ArrangedContentVariable,  or; 

b)  any  number  and  combination  of  fixed  positioned  frames  of  the  types 
SourcedContentFixed  and  ArrangedContentFixed. 

In  case  b),  the  subordinate  frames  may  overlap  without  restriction. 
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6.3.7  Sourced  content  and  arranged  content  area  characteristics 


6.3.7.1  SourcedContentVariable 

A  SourcedContentVariable  frame  is  a  constituent  constraint  that  defines  a  lowest  level  frame  that 
contains  common  content  derived  from  the  generic  logical  structure.  This  frame  is  variably  positioned 
and  is  used  for  the  positioning  content  which  is  generated  during  the  layout  process,  such  as  a 
character  sequence  containing  a  page  number,  a  chapter  title,  etc. 

This  frame  may  be  placed  in  the  body  area  as  well  as  the  header  or  footer  area: 

—  When  this  frame  is  in  the  header  or  footer  area,  it  is  the  immediate  subordinate  of  the 
frame  of  the  constituent  constraint  type  CompositeHeader  or  CompositeFooter. 

—  When  this  frame  is  in  the  body  area,  it  is  the  immediate  sutxDrdinate  of  the  frame  of  the 
constituent  constraint  type  VariableCompositeBody,  CompositeColumnVariable, 
CompositeColumnFixed,  CompositeCommon,  SnakingColumns  or  CompositeFloat. 

SnakingColumns  are  used  to  place  common  contents  in  the  multi-column  format.  CompositeFloat 
is  used  to  place  comnron  contents  along  side  a  figure  or  a  form. 

The  attribute  "logical  source"  must  be  specified  for  this  frame  to  indicate  the  particular  instance  of  the 
constituent  constraint  CommonContent  which  contains  the  content  to  be  laid  out. 

When  this  frame  is  a  subordinate  of  CompositeHeader  or  CompositeFooter; 

a)  the  layout  path  of  the  frame  is: 

-  270  degrees  for  H/F  layouts  A1  and  A2; 

-  180  degrees  for  H/F  layouts  B1  and  B2  (see  6.3.4.5  and  the  comment  in  7.4.3.21). 

b)  the  horizontal  dimension  of  the  frame  is: 

-  either  fixed  or  maximum-size'  for  H/F  layouts  A1.  A2  and  82; 

-  either  fixed  or  Rule-B'  for  H/F  layout  B1 . 

c)  the  vertical  dimension  of  the  frame  is: 

-  either  fixed  or  *Rule-B'  for  H/F  layouts  A1  and  A2; 

-  either  fixed  or  maximum-size'  for  H/F  layout  B1 ; 

-  only  fixed  in  the  case  of  H/F  layout  B2. 

When  this  frame  is  a  subordinate  of  VariableCompositeBody,  CompositeColumnVariable, 
CompositeColumnFixed  or  CompositeCommon: 

a)  the  layout  path  of  the  frame  is  270,  0  or  180  degrees  for  body  layouts  A,  B  or  C 
respectively  (see  6.3.4.5  and  the  comment  in  7.4.3.21); 

b)  the  dimension  of  the  frame  in  the  direction  orthogonal  to  the  layout  path  of  the  superior 
frame  is  either  fixed  or  maximum-size'; 
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c)  the  dimension  of  the  frame  In  the  direction  parallel  to  the  layout  path  of  the  superior 
frame  is  either  fixed  or  'Rule-B'. 

When  this  frame  is  a  subordinate  of  SnakingColumns: 

a)  the  layout  path  of  the  frame  is  270.  0  or  180  degrees  for  body  layouts  A,  B  or  C 
respectively  (see  6.3.4.5  and  the  comment  in  7.4.3.21); 

b)  the  dimension  of  the  frame  in  the  direction  orthogonal  to  the  layout  path  of  the  superbr 
frame  is  either  'Rule-B'  or  'maximum-size',  except  that  only  maximum-size'  is  permitted 
for  body  layout  C; 

c)  the  dimension  of  the  frame  in  the  direction  parallel  to  the  layout  path  of  the  supertor 
frame  is  fixed. 

When  this  frame  is  a  subordinate  of  CompositeFloat: 

a)  the  layout  path  of  the  frame  is  270.  0  or  180  degrees  for  body  layouts  A.  B  or  C 
respectively  (see  6.3.4.5  and  the  comment  in  7.4.3.21); 

b)  the  dimension  of  the  frame  in  the  direction  orthogonal  to  the  layout  path  of  the  superior 
frame  is  either  fixed.  'Rule-B'  or  maximum-size"; 

c)  the  dimension  of  the  frame  in  the  direction  parallel  to  the  layout  path  of  the  superior 
frame  is  either  fixed  or  "Rule-B". 


6.3.7.2  ArrangedContentVarlable 

An  ArranqedContentVariable  frame  is  a  constituent  constraint  that  defines  a  lowest  level  frame  that 
contains  pre-defined  common  content  contained  in  the  generic  layout  structure.  This  frame  is  variably 
positioned,  and  its  dimensbns  are  fixed. 

This  frame  references  one  or  more  blocks  of  type  GenericBlock  (see  6.3.8)  which  contain  the  content  to 
t>e  laid  out  in  this  frame.  Thus,  this  frame  is  typically  used  when  it  is  required  to  layout  pre  determined 
common  content. 


6.3.7.3  SourcedContentFixed 

A  SourcedContentFixed  frame  is  a  constituent  constraint  that  defines  a  lowest  level  frame  that  contains 
common  content  derived  from  the  generic  logical  structure.  This  frame  has  a  fixed  position  and 
dimensions. 

This  frame  is  required  to  specify  the  attribute  "logical  source"  which  indicates  the  particular  instance  of 
the  constituent  constraint  CommonContent  which  contains  the  content  to  be  laid  out  in  this  frame. 


This  frame  may  be  placed  in  the  body  area  as  well  as  the  header  or  footer  area: 

—  When  this  frame  is  in  the  header  or  footer  area,  the  frame  is  the  immediate  sutwrdinate 
of  the  frame  of  the  constituent  constraint  type  CompositeHeader  or  CompositeFooter; 
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—  When  this  frame  is  in  the  body  area,  the  frame  is  the  immediate  subordinate  of  the 

frame  of  the  constituent  constraint  type  FixedCompositeBody,  CompositeCommon  or 
,  SynchronizedColumns. 


When  this  frame  is  a  subordinate  of  CompositeHeader  or  CompositeFooter: 


—  the  layout  path  of  this  frame  is  270  degrees  for  H/F  layouts  A1  and  A2; 

—  the  layout  path  of  this  frame  is  180  degrees  for  H/F  layouts  B1  and  82  (see  6.3.4.5). 

When  this  frame  is  a  sutx)rdinate  of  FixedCompositeBody,  CompositeCommon  or  SyncronizedColumns: 

—  the  layout  path  of  this  frame  is  270,  0  or  180  degrees  for  body  layouts  A,  B  or  C 
respectively  (see  6.3.4.5). 


Thus,  as  in  the  case  of  SourcedContentVariable  frames,  this  frame  is  used  for  the  positioning  of  content 
which  is  generated  during  the  layout  process,  such  as  a  character  sequence  containing  a  page  numt>er. 


6.3.7.4  ArrangedContentFixed 

An  ArrangedContentFixed  frame  is  a  constituent  constraint  that  defines  a  lowest  level  frame  that 
contains  pre-defined  common  content  derived  from  the  generic  layout  structure.  The  position  and 
dimensions  of  this  frame  are  fixed. 

This  frame  references  one  or  blocks  of  type  GenericBlock  (see  6.3.8)  which  contain  the  content  to  be 
laid  out  in  this  frame.  Thus  this  frame  is  typically  used  when  it  is  required  to  layout  common  content  at 
pre-determined  positions  in  the  header  or  footer  areas. 


6.3.8  GenericBlock  and  SpecificBlock 

Two  types  of  constituent  constraints  of  the  type  'block*  are  defined,  namely  GenericBlock  and 
SpecificBlock. 


Object  classes  of  the  type  GenericBlock  may  occur  in  the  generic  layout  structure  referenced  by  the 
"generator  for  subordinates"  of  object  classes  of  the  types  ArrangedContentVariable  and 
ArrangedContentFixed.  When  the  layout  process  is  performed  to  produce  a  document  in  formatted 
processable  form,  equivalent  blocks  may  occur  in  the  specific  layout  structure. 

Objects  of  the  type  SpecificBlock  shall  only  occur  in  the  specific  layout  structure.  They  are  created 
during  the  document  layout  process  and  result  from  the  layout  of  basic  logical  objects  into  lowest  level 
frames  that  constitute  the  body,  header  and  footer  areas. 


6.4  Document  layout  characteristics 

Mechanisms  for  controlling  the  allocation  of  logical  constituents  to  various  areas  in  the  layout  structure 
are  defined  in  6.4.1 .  Mechanisms  for  controlling  the  layout  of  the  content  within  the  allocated  areas  are 
defined  in  6.4.2. 

These  mechanisms  relate  to  documents  for  which  a  generic  layout  structure  is  specified.  When  a 
generic  layout  structure  is  not  present,  then  these  mechanisms  are  restricted  as  described  in  6.4.3. 


i! 
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6.4.1  Flow  controls 


Various  mechanisms  are  provided  to  control  the  allocation  ot  constituent  constraints  representing  the 
'body'  parts  of  the  logical  structure  of  a  document  to  page  sets,  pages  and  body  areas.  These  are 
described  in  6.4.1.1.  6.4.1.2  and  6.4.1.3.  The  mechanisms  for  controlling  the  layout  of  the  'common' 
parts  of  a  document  are  described  in  6.4.1.4. 


6.4.1.1  Allocation  of  content  to  page  sets 

Two  methods  of  allocating  the  constituent  constraints  associated  with  the  'body'  part  of  the  document  to 
page  sets  are  provided. 

a)  layout  in  a  nominated  page  set; 

b)  starting  a  new  page  set. 

The  first  method  provides  the  ability  to  specify  that  a  part  of  a  document  is  to  be  laid  out  entirely  within 
a  specified  page  set.  This  may  be  specified  for  constituent  constraints  of  the  types  Passage. 
NumberedSegment.  Paragraph,  Figure.  NumberedList.  UnNumberedList  and  DefinitionList  using  the 
attribute  "layout  object  class"  which  specifies  the  object  class  identifier  of  the  required  class  of  page  set. 

The  second  method  provides  the  ability  to  specify  that  the  logical  objects  derived  from  a  particular 
logical  constituent  constraint  in  a  document  and  all  subsequent  parts  of  a  document  are  to  be  laid  out 
starting  at  the  beginning  of  a  new  page  set.  This  may  be  specified  for  logical  object  from  the  following 
logical  constituent  constraints: 

—  Passage; 

—  NumberedSegment; 

—  Number; 

—  Title; 

—  Paragraph;  ' 

—  Figure; 

—  NumberedList; 

—  UnNumberedList; 

—  DefinitionList; 

—  Body  Text; 

—  BodyRaster; 

—  BodyGeometric. 

This  is  achieved  using  the  attribute  "new  layout  object"  which  specifies  the  object  class  identifier  of  the 
required  class  of  page  set. 
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6.4.1.2  Page  breaks 

This  provides  the  ability  to  specify  that  the  logical  objects  derived  from  a  particular  logical  constituent 
constraint  in  a  document  and  all  subsequent  parts  of  a  document  are  to  be  laid  out  starting  at  the 
beginning  of  a  new  page.  The  page  specified  shall  belong  to  the  page  set  in  which  the  logical  objects 
from  the  immediate  preceding  logical  constituent  constraint  is  laid  out  (see  note). 

This  may  be  specified  for  logical  objects  from  the  following  logical  constituent  constraints: 

—  Passage; 

—  NumberedSegment; 

—  Number; 

—  Title; 

—  Paragraph; 

—  Figure; 

—  NumberedList; 

—  UnNumberedList; 

—  DefinitionList; 

—  BodyText; 

—  BodyRaster; 

—  BodyGeometric. 

This  is  achieved  using  the  attribute  "new  layout  object".  This  attribute  may  specify  the  value  page' 
indicating  that  the  logical  object  is  to  be  laid  out  starting  on  the  next  available  page  which  may  be  of 
any  class.  Alternatively,  the  attribute  may  specify  an  object  class  identifier  indicating  the  page  class 
that  the  object  is  to  be  laid  out  in. 

NOTE  18  -  The  specification  of  a  page  breaks  shall  not  be  used  to  layout  part  of  a  document  in  a  new  page 
set.  If  a  new  page  set  is  required,  then  this  shall  be  explicitly  specified  as  described  in  6.4.1.1. 

6.4.1.3  Allocation  of  content  to  body  areas 
6.4.1.3.1  Introduction 

If  the  page  to  which  the  content  is  allocated  contains  a  basic  lx)dy  area,  then  the  content  is  laid  out  in 
sequential  order  in  that  body  area  in  the  form  of  a  single  column. 

If  the  page  contains  a  composite  body  area,  i.e.,  a  VariableCompositeBody  or  FixedCompositeBody 
frame,  then  the  content  is  allocated  to  subordinate  areas  in  that  body  area  as  described  below. 

The  general  layout  mechanism  is  described  in  6.4.1.3.2.  However,  particular  layout  facilities  are 
provided  for  the  layout  of  logical  constituent  constraints  of  the  type  Table  (see  6.4.1.3.8)  and  the  type 
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Figure,  which  may  contain  either  Artwork  or  Forms  (see  6.4.1 .3.7).  Also,  the  layout  of  Footnotes  is 
described  in  6.4.1.3.10. 


6.4.1.3.2  General  mechanism  for  laying  out  content  in  a  composite  body  area 

When  laying  out  content  into  a  composite  txDdy  area  having  more  than  one  sutx)rdinate  frame  class 
(excluding  FootnoteArea  frame  classes),  It  is  necessary  to  indicate,  directly  or  indirectly,  which  of  the 
possible  areas  is  to  be  used. 

Basic  logical  objects  other  than  those  which  are  within  a  footnote  structure  may  be  specified  to  be  laid 
out  in  instances  of  one  or  more  lowest  level  frame  class.  This  is  done  by  giving  each  such  basic  logical 
component  a  value  of  the  attribute  "layout  category"  which  corresponds  to  the  value  of  the  attribute 
"permitted  categories"  that  applies  to  the  lowest  level  frame  in  which  the  content  is  to  be  laid  out. 

Note  that  any  basic  logical  objects  in  the  specific  logical  structure  to  which  this  attribute  does  not  apply 
will  be  laid  out  only  in  a  lowest  level  frame  which  has  the  implicit  value  of  the  attribute  "permitted 
categories". 

The  use  of  the  attribute  "layout  category"  ensures  that  it  there  is  insufficient  area  on  one  page  to  lay  out 
all  of  the  content  allocated  to  a  particular  type  of  area,  the  laying  out  of  the  content  will  automatically 
continue  in  the  same  type  of  area  in  a  succeeding  page  when  possible.  Thus  content  is  allowed  to  flow 
freely  from  one  page  to  another  when  the  type  of  layout  used  at  the  end  of  one  page  is  the  same  as 
that  at  the  beginning  of  the  succeeding  page.  When  continuation  to  the  same  type  of  area  in  a 
succeeding  page  is  not  possible  because  of  conflict  with  other  layout  directives  or  because  the 
"generator  for  subordinates"  of  the  page  class  does  not  allow  such  choice,  backtracking  may  occur  or 
other  type  of  area  may  be  selected. 

It  is  necessary  to  ensure  the  correct  use  of  the  mechanism  for  the  layout  of  independent  layout 
streams.  In  the  absence  of  additional  layout  directives,  content  may  be  placed  in  available  space  within 
an  earlier  frame  of  the  specified  "permitted  categories".  If  this  is  not  intended,  it  may  be  prevented  by 
the  use  of  the  attribute  "new  layout  object"  (or  "layout  object  class"  in  some  cases). 

The  attribute  "new  layout  object"  may  be  applied  to  logical  components  whenever  a  change  in  layout  is 
required.  The  attribute  "new  layout  object"  may  specify  the  identifier  or  the  category  name 
corresponding  to  the  frame  class  that  is  required. 

When  layout  occurs  in  a  snaking  columns  area,  column  breaks  may  be  indicated  by  using  the  attribute 
"new  layout  object".  This  attribute  may  specify  the  identifier  or  the  category  name  of  the  frame 
corresponding  to  the  column  in  which  the  layout  is  to  continue.  However,  only  the  use  of  category 
name  will  ensure  that  a  single  column  break  is  always  obtained,  irrespective  of  the  frame  class  actually 
used. 

When  the  layout  is  to  occur  in  a  synchronized  columns  area,  category  names  may  be  used  to  control 
the  particular  columns  that  are  to  be  used  to  lay  out  the  logical  entities.  Each  column  within  a 
synchronized  columns  area  shall  have  a  different  permitted  category  and  each  basic  logical  object  to  be 
laid  out  in  this  particular  area  shall  have  a  category  name  corresponding  to  a  name  allocated  to  one  of 
the  columns.  The  logical  entities  allocated  to  different  columns  may  be  aligned  using  the  attribute 
"Synchronization". 

The  following  sulx:lauses  describe  the  layout  mechanism  applicable  to  subordinate  areas  for  each  of 
the  frame  types  listed  atx)ve. 
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6.4.1.3.3  Layout  into  BasicFloat  and  BasicFixture  frames 

These  are  lowest  level  frames  and  hence  content  continues  to  be  directly  laid  out  in  these  frame  types 
until  an  occurrence  of  the  attribute  "new  layout  object"  causes  the  layout  to  proceed  starting  with  an 
alternative  frame  class. 


6.4.1.3.4  Layout  in  SnaltingColumns  frames 

A  SnakingColumns  frame  is  a  composite  frame  which  contains  columns  represented  by  lowest  level  or 
composite  frames. 

In  the  case  of  lowest  frames,  all  the  frames  may  have  the  same  category  name  so  that  content  can 
flow  from  one  frame  to  the  next.  That  is,  a  column  break  will  occur  naturally  when  the  size  of  one 
column  reaches  the  limit  imposed  by  the  superior  frame  and  the  layout  process  will  continue 
automatically  in  the  next  column. 

In  the  case  of  composite  columns,  the  subordinate  areas  are  represented  by  subordinate  frames  of  the 
types  BasicFloat,  CompositeFloat,  CompositeFixture Variable,  TableArea  and  FootnoteArea.  The  frame 
type  into  which  the  constituents  are  to  be  laid  out  is  selected  using  the  attribute  "new  layout  object" 
which  indicates  the  identifier  or  category  name  of  the  required  subordinate  frame,  or  is  automatically 
selected  according  to  "layout  categories".  Logical  constituents  will  continue  to  be  laid  out  in  the 
selected  frame  type  until  a  different  frame  type  is  selected.  Also,  the  layout  process  continues 
automatically  from  one  column  to  the  next,  but  column  breaks  can  again  be  forced  as  described  in 
6.4.1.3.2. 


6.4.1.3.5  Layout  in  SynchronizedColumns  frames 

A  SynchronizedColumns  frame  is  a  composite  frame  which  contains  columns  represented  by 
subordinate  lowest  level  or  composite  frames. 

In  the  case  of  lowest  frames,  all  the  frames  are  required  to  have  different  categories.  Hence,  the  layout 
of  logical  objects  from  the  constituents  into  different  columns  is  controlled  by  the  category  name 
specified  for  each  constituent.  The  attribute  "new  layout  object"  may  also  be  used  for  this  purpose,  but 
this  is  not  necessary. 

In  the  case  of  composite  columns,  the  subordinate  areas  are  represented  by  subordinate  frames  of  the 
types  BasicFloat,  CompositeFloat,  CompositeFixture  Variable,  TableArea  and  FootnoteArea. 

The  selection  of  a  particular  composite  column  or  a  particular  sub-area  within  a  composite  column  can 
be  achieved  using  the  attribute  "new  layout  object"  which  specifies  the  identifier  or  category  name  of 
the  particular  frame  class  required. 


6.4.1.3.6  Layout  in  CompositeFloat  frames 

This  is  a  composite  frame  which  contains  two  or  more  subordinate  frames  that  are  laid  out  'side-by- 
side'.  The  appropriate  subordinate  frame  is  chosen  according  to  the  category  names  or  chosen  using 
the  attribute  "new  layout  object"  which  specifies  the  appropriate  identifier  or  category  name  of  the 
required  subordinate  frame  class. 
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6.4.1.3.7  Layout  of  Figures 

Frames  of  tfie  types  CompositeFixtureVariable  and  CompositeFixtureFixed  are  provided  specifically  for 
the  layout  of  logical  constituent  constraints  of  the  type  Figure.  Similarly,  frames  of  the  type 
CompositeArlwork  and  FormArea  are  provided  for  the  layout  of  logical  constituent  constraints  of  the 
types  Artwork  and  Form  respectively.. 

The  schematic  diagram  in  table  2  shows  how  the  logical  constituent  constraint  Figure  and  Its 
sutwrdinates  are  allocated  to  the  frame  CompositeFixtureVariable  or  CompositeFixtureFixed  and  their 
sut^ordinates. 


Table  2  —  Layout  of  Figure 


Logical  constituent  constraint 

Frame  class 

Figure  > 

CompositeFixtureVariable  or  ComposrteFixtureFixed 

Artwork  > 

CompositeArtwork 

Phrase  > 

BasicFixture 

Body  Raster  > 

BasicFixture 

BodyGeometric  > 

BasicFixture 

Form  > 

FormArea 

EnlryGroup  > 

EntryGroupArea 

EntryElement  ....> 

FormEntryArea 

Number  > 

BasicFloat 

Caption  > 

BasicFloat 

Description  > 

BasicFloat 

Footnote  > 

FootnoteArea 

Table  2  indicates  a  mapping  between  logical  constituent  constraints  and  frames,  and  their  respective 
subordinates.  Also,  the  diagram  indicates  that  this  mapping  is  hierarchical. 

For  example.  Figure  is  to  be  laid  out  into  a  single  instance  of  the  frame  CompositeFixtureVariable  or 
CompositeFixtureFixed.  A  subordinate  constituent  constraint  of  the  type  Artwork  is  to  be  laid  out  in  a 
single  instance  of  a  frame  of  type  CompositeArlwork  within  the  specified  CompositeFixtureVariable  in  a 
CompositeFixtureFixed  frame. 

Also,  each  instance  of  a  subordinate  Phrase,  BodyRaster  or  BodyGeometric  is  to  be  laid  out  in  a  single 
instance  of  a  sutx)rdinate  frame  of  the  type  BasicFixture.  BasicFixture  frames  may  overlap  to  form  a 
composite  image. 

Similarly,  a  Form  is  to  be  laid  out  in  a  single  instance  of  a  FormArea  frame.  Frames  subordinate  to  this 
FormArea.  that  is.  EntryGroupArea  and  FormEntryArea  frames,  will  each  receive  single  instances  of 
logical  constituent  constraints  of  the  type  EntryGroup  and  EntryElement  respectively. 
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This  layout  mechanism  is  achieved  by  specifying  the  attribute  "new  layout  object"  for  Figure  with  a 
value  indicating  the  identifier  of  the  appropriate  frame  classes  in  which  that  constituent  is  to  be  laid  out. 

The  constituent  constraints  Number,  Caption  and  Description  (and  their  sulx)rdinates  in  the  case  of 
Caption  and  Description)  are  laid  out  in  frames  of  the  type  BasicFloat.  This  is  achieved  automatically 
according  to  category  names  or  explicitly  using  the  attribute  "new  layout  object"  which  indicates  the 
identifier  or  category  name  of  the  frame  class  required.  More  than  one  instance  of  the  constituent 
constraints  Caption,  Description  and  Number  may  be  laid  out  in  a  particular  BasicFloat  frame. 

Frames  of  the  type  FootnoteArea  may  be  generated  within  a  CompositeFixtureVariable  or 
CompositeFixtureFixed  to  accommodate  instances  of  the  logical  constituent  constraint  Footnote  which 
occurs  as  a  subordinate  of  Phrase,  Caption  or  Description. 


6.4.1.3.8  Layout  of  Tables 

Frames  of  the  type  TableArea  are  provided  specifically  for  the  layout  of  logical  constituent  constraints  of 
the  type  Table. 

Table  3  illustrates  the  relationships  between  the  logical  constituent  constraint  Table  and  its 
subordinates,  and  the  frames  used  to  lay  out  these  constituent  constraints. 


Table  3  —  Layout  of  Tables 


Logical  constituent  constraint 

Frame  class 

Table  > 

TableArea 

Row  > 

RowArea 

EntryEiement  > 

Cell 

TableComponent  > 

SubRowGroup 

RowComponent  > 

SubRow 

EntryEiement  > 

Cell 

CommonContent  <  

TableHeader 

CommonContent  <  

TableLabel 

Table  3  indicates  that  there  is  a  hierarchical  mapping  between  logical  constituent  constraints  and  their 
corresponding  frames.  For  example,  each  Row  is  to  be  laid  out  in  a  separate  frame  of  the  type 
RowArea.  Each  TableComponent  that  is  sutwrdinate  to  that  Row  must  be  laid  out  in  a  specific 
SubRowGroup  that  is  sutx)rdinate  to  the  RowArea  indicated. 
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The  layout  mechanism  is  achieved  for  the  logical  constituent  constraints  Table.  Row  and 
RowComponent  by  specifying  the  attribute  "new  layout  object"  with  a  value  indicating  the  identifier  of 
the  required  frame  class  of  the  type  TableArea,  RowArea  and  SubRow  respectively. 

For  the  logical  constituent  constraint  Entry  Element,  the  layout  mechanism  is  achieved  by  one  of  the 
following: 

a)  If  the  attribute  "generator  for  sutxjrdinates"  of  the  superior  (RowArea  or  SubRow)  of  the 
affected  EntryElement  is  constructed  using  SEQuence,  the  attribute  "new  layout  object" 
is  used  to  specify  a  Cell  into  which  the  contents  is  laid  out.  The  attribute  value  specifies 
the  identifier  of  the  required  frame  class  in  the  EntryElement. 

b)  If  the  attribute  "generator  for  subordinates"  of  the  superior  {RowArea  or  SubRow)  of  the 
affected  EntryElement  is  constructed  by  REPetition,  the  value  of  the  attribute  "new 
layout  object"  indicates  a  category  name  to  be  used  for  the  EntryElement.  In  this  case, 
the  category  name  shall  be  specified  in  the  attribute  "layout  category"  for  EntryText, 
EntryRaster  or  EntryGeometric,  and  in  the  attribute  "permitted  categories"  for  the  Cell 
into  which  the  contents  is  laid  out. 

In  the  case  of  TableComponent.  the  attribute  "layout  object  class"  is  used  to  specify  that  this  logical 
constituent  constraint  is  to  be  laid  out  in  a  SubRowGroup  frame. 

This  mechanism  allows  a  table  to  be  laid  out  such  that  it  is  split  over  two  or  more  successive  frames  or 
pages.  A  split  may  occur  at  the  boundary  of  a  RowArea  frame,  or  such  that  a  RowArea  frame  is  split 
over  two  successive  frames  or  pages.  A  split  cannot  occur  within  a  SubRowGroup  frame. 

When  such  a  split  does  occur,  then  the  TableHeader  and  TableLabel  frames  are  repeated  at  the  top  of 
each  frame  of  page  in  which  the  table  is  continued. 

The  content  allocated  to  the  frames  TableHeader  and  TableLabel  are  derived  from  logical  constituent 
constraints  of  the  type  CommonContent  in  the  generic  logical  structure  using  the  'logical  source' 
mechanism. 


6.4.1.3.9  Layout  Of  Forms 

Frames  of  the  type  FormArea  are  provided  specifically  for  the  layout  of  logical  constituent  constraints  of 
the  type  Form. 

Table  4  illustrates  the  relationships  between  the  logical  constituent  constraint  Form  and  its 
subordinates,  and  the  frames  used  to  lay  out  these  constituent  constraints. 

Table  4  indicates  there  is  a  hierarchical  mapping  between  logical  constituent  constraints  and  the 
corresponding  frames,  and  their  respective  subordinates. 

The  layout  mechanism  is  achieved  by  specifying  for  logical  constituent  constraints  the  attribute  "layout 
object  class"  which  indicates  the  object  class  identifier  of  an  appropriate  frame  in  accordance  with  the 
above  diagram.  This  mechanism  does  not  allow  frames  of  the  type  FormArea  to  be  split  over  two  or 
more  superior  frames. 

The  content  associated  with  the  logical  constituent  constraint  EntryElement  is  specified  by  one  of  the 
constituent  constraints  EntryText,  EntryRaster  or  ErrtryGeometric.  The  layout  of  this  content  is 
controlled  by  the  layout  directives  "offset"  and  "block  alignment". 
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Table  4  —  Layout  of  Forms 


Logical  constituent  constraint 

Frame  class 

Form  > 

FormArea 

EntryGroup  > 

EntryGroupArea 

EntryElemenl  > 

FormEntryArea 

^  1  'l 


6.4.1.3.10  Layout  of  Footnotes 

The  logical  objects  derived  from  basic  logical  constituent  constraints  that  represent  the  content 
belonging  to  a  footnote  (i.e.,  FootnoteReference,  FootnoteNumber  and  FootnoteText)  are  constrained  to 
be  laid  out  in  a  footnote  area  which  is  represented  by  a  FootnoteArea  frame  (see  6.3.5.20). 

This  constraint  is  specified  by  means  of  category  names.  That  is,  the  logical  constituent  constraints  of 
the  types  FootnoteNumber  and  FootnoteText,  and  layout  constituent  constraints  of  the  type 
FootnoteArea  are  all  required  to  have  the  category  name  Footnote'  or  'Footnote  <n>'. 

More  than  one  footnote  may  be  placed  in  a  footnote  area.  In  this  case,  the  content  belonging  to  the 
footnotes  are  laid  out  sequentially  in  the  footnote  area  in  accordance  with  their  reading  order. 

If  the  content  belonging  to  a  footnote  cannot  all  be  accommodated  in  the  footnote  area  on  one  page, 
then  the  content  may  freely  flow  into  the  next  footnote  area.  Alternatively,  it  is  possible  to  specify  that  a 
footnote  is  to  be  laid  out  entirely  within  a  particular  footnote  area.  This  is  achieved  using  the  attribute 
"indivisibility". 


6.4.1.4  Allocation  of  content  to  header  and  footer  areas 

A  header  or  footer  area  may  be  basic  or  composite  (see  6.3.6.1).  In  the  case  of  a  basic  area,  the 
frame  representing  that  area  specifies  the  attribute  "logical  source"  which  indicates  the  particular 
Instance  of  the  constituent  constraint  of  the  type  CommonContent  that  is  to  be  laid  out  in  that  area. 
The  basic  logical  constituent  constraints  subordinate  to  CommonContent  are  then  laid  out  in 
accordance  with  their  sequential  order. 

In  the  case  of  a  composite  header  or  footer  area  (see  6.3.6.3),  the  area  is  divided  into  one  or  more 
separate  areas,  each  of  which  is  represented  by  a  lowest  level  frame.  The  content  allocated  to  the 
separate  areas  may  be  derived  from  one  of  two  sources.  That  is,  the  content  may  be  pre-defined  and 
represented  by  one  or  more  blocks  which  are  directly  associated  with  the  lowest  level  frame. 
Alternatively,  the  lowest  level  frame  may  specify  the  attribute  "logical  source"  which,  as  above,  indicates 
the  particular  logical  object  of  the  type  CommonContent  that  is  to  be  laid  out  in  that  frame. 


6.4.2  Layout  of  document  content 

Various  constraints  may  be  specified  to  control  the  layout  of  the  content  into  the  body,  header  and 
footer  areas.  These  constraints  are  described  below. 
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6.4.2.1  Margins 


The  margins  are  the  minimum  distances,  or  offsets,  between  a  part  of  the  document  content  and  the 
edge  of  the  particular  area  in  which  that  content  is  laid  out.  The  margins  define  the  maximum  extents 
of  the  available  area  into  which  the  content  shall  be  positioned. 

Margins  may  be  specified  for  any  constituent  constraint  representing  a  basic  logical  object;  different 
margin  values  may  be  specified  for  different  constituent  constraints  without  restriction. 

Four  margins  may  be  independently  specified  for  each  constituent  constraint,  namely: 

—  trailing  edge  margin; 

—  leading  edge  margin; 

—  right  hand  edge  margin; 

—  left  hand  edge  margin. 

These  margins  are  defined  in  relationship  to  the  layout  path  specified  for  the  frame  into  which  the 
content  is  to  be  laid  out  (see  figure  18). 

Any  combination  of  the  above  margins  may  be  specified  for  a  particular  constituent  constraint.  These 
margins  are  specified  by  the  attribute  "offset".  Any  value  may  be  specified  in  units  of  StvlUs.  If  a 
particular  margin  is  not  specified,  then  it  is  assumed  to  be  0  Sty^Us. 


6.4.2.2  Separation 

Leading  separation  is  the  minimum  distance  between  one  basic  logical  object  and  the  next  one,  if  any, 
when  they  are  laid  out.  Trailing  separation  is  the  minimum  distance  between  one  basic  logical  object 
and  the  previous  one,  if  any,  when  they  are  laid  out.  Both  may  be  specified  for  basic  logical 
components  of  any  constituent  constraint  types.  These  distances  are  specified  in  SMUs  by  the 
attribute  "separation".  If  no  value  is  specified,  then  the  minimum  distance  is  assumed  to  be  0  SMUs. 


6.4.2.3  Indivisibility 

Indivisibility  provides  the  means  to  specify  whether  or  not  a  logical  object  derived  from  a  basic  or 
composite  bgical  constituent  constraint  is  allowed  to  be  split  over  more  than  one  page  or  over  more 
than  one  area  within  a  page.  It  may  be  specified  for  logical  objects  from  constituent  constraints  of  the 
types  Passage,  NumberedSegment,  Number,  Title,  Paragraph.  Captbn,  Phrase,  Reference, 
Description,  Listltem,  ListTerm.  FootnoteText,  ReferencedContent,  FootnoteBody,  Artwork, 
EntryElement,  Row,  RowComponent,  Footnote,  Figure,  Table,  UnNumberedList,  NumberedList, 
DefinitionList,  FootnoteReference  and  BodyText.  The  attribute  "indivisibility"  is  used  to  specify  this 
feature. 


6.4.2.4  Same  layout  object 

Same  layout  object  provides  the  means  to  specify  that  the  start  of  the  content  associated  with  a  logical 
object  and  the  end  of  the  content  associated  with  the  previous  logical  object  are  to  be  laid  out  within  a 
single  layout  object.  This  may  be  specified  for  logical  objects  of  the  types  Passage, 
NumberedSegment,  Title,  Caption.  Number,  Paragraph.  Phrase,  Footnote,  FootnoteBody,  Figure, 
FootnoteReference,  ReferencedContent,  Reference.  Description,  Table.  NumberedList. 
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Figure  18  —  Specification  of  margins 


UnNumberedList,  DefinitionList.  Listltem.  ListTerm,  BodyText,  BodyRaster  and  BodyGeometric.  The 
attribute  "same  layout  object"  is  used  to  specify  this  feature. 


6.4.2.5  Concatenation 

Concatenation  provides  the  means  to  specify  that  the  content  associated  with  a  logical  object  derived 
from  a  basic  logical  constituent  constrairit  and  the  content  associated  with  the  previous  basic  logical 
object  are  to  be  regarded  as  an  unbroken  stream  of  content.  This  may  be  specified  for  logical  objects 
from  constituent  constraints  of  the  types  BodyText,  Number.  ReferencedContent,  FootnoteReference, 
FootnoteText.  TableNumber,  Currentlnstance,  CommonNumber,  CommonReference,  CommonText  and 
PageNumber.  The  attribute  "concatenation"  is  used  to  specify  this  feature. 


6.4.2.6  Block  alignment 

Block  alignment  allows  the  content  associated  with  a  basic  logical  object  to  be  specified  as  'left 
aligned',  right  aligned'  or  centred'  within  the  area  in  which  that  content  is  laid  out.  Left  aligned  means 
that  the  content  is  laid  out  adjacent  to  the  left  hand  edge  margin.  Right  aligned  means  that  the  content 
is  laid  out  adjacent  to  the  right  hand  edge  margin,  and  centred  means  that  the  content  is  laid  out 
midway  between  the  left  and  right  margins. 
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This  feature  may  only  be  specified  using  the  attribute  "block  alignment"  for  logical  objects  from 
constituent  constraints  of  the  types  BodyText,  EntryText,  Number.  CommonNumber,  PageNumber. 
TableNumber,  FootnoteNumber,  FootnoteText,  FootnoteReference,  CommonReference, 
ReferencedContent,  Currentlnstance,  and  ComnnonText,  and  when  they  contain  formatted  character 
content,  BodyRaster,  and  BodyGeometric.  EntryRaster.  EntryGeometric,  CommonRaster  and 
CommonGeometric. 


6.4.3  Layout  controls  applicable  In  the  absence  of  a  generic  layout  structure 

In  processable  form  documents  the  generic  layout  structure  is  optional.  If  the  generic  layout  structure  is 
omitted,  then  it  is  the  responsibility  of  the  receiver  to  define  an  appropriate  layout  structure.  No 
limitations  are  placed  on  the  layout  structure  that  is  used. 

When  a  generic  layout  structure  is  not  specified  within  a  processable  form  document,  then  restrictions 
are  placed  on  the  layout  control  functions  described  in  6.4.1  and  6.4.2  that  may  be  specified  within  the 
document.  These  restrictions  are  indicated  as  follows: 

a)  It  is  not  possible  to  specify  that  certain  logical  parts  of  a  document  are  to  be  allocated 
to  a  given  page  set  or  that  a  part  of  a  document  is  to  be  laid  out  starting  in  a  new  page 
set,  as  defined  in  6.4.1.1; 

b)  It  is  possible  to  specify  page  breaks  as  defined  in  6.4.1.2,  but  it  is  only  possible  to 
indicate  that  the  layout  shall  begin  on  a  new  page.  It  is  not  possible  to  specify  a 
particular  page  class; 

c)  The  logical  parts  of  the  document  that  are  intended  to  be  laid  out  in  the  body  area  and 
in  the  header/footer  areas  of  each  page  may  be  distinguished  from  each  other  by 
means  of  application  comments  specified  for  them  (see  6.6.5).  An  exception  is  that  it  is 
not  possible  to  distinguish  whether  a  particular  portion  of  common  content  is  to  be 
placed  in  a  header  or  a  footer  area  (or  both); 

d)  It  is  not  possible  to  indicate  the  type  of  layout  area  to  be  used  to  layout  each  logical 
constituent  in  the  t)0dy  part  of  a  document.  That  is,  it  is  not  possible  to  indicate 
whether  single  column  or  multiple  column  areas  are  to  be  used  (see  6.4.1.3).  This 
shall  be  decided  by  the  receiver; 

e)  Footnotes  within  the  tDody  part  of  a  document  may  be  distinguished  by  use  of  the 
attribute  "application  comments".  Footnotes  are  intended  to  be  read  and  laid  out 
separately  from  the  other  logical  constituents  of  the  body  part  (see  6.4.1.3).  However, 
it  is  the  responsibility  of  the  receiver  to  decide  how  footnotes  are  laid  out; 

f)  Margins,  separation,  indivisibility,  same  layout  object,  concatenation  and  block 

alignment,  as  defined  in  6.4.2,  may  all  be  specified.  Only  one  restriction  applies.  . 
Indivisibility  (see  6.4.2.3)  may  be  assumed  to  specify  that  a  logical  constituent 
constraint  is  not  to  split  over  more  than  one  page,  but  indivisibility  shall  not  be  specified 
for  other  types  of  layout  areas,  such  as  single  or  muttiple  column  areas. 


6.5  Content  layout  and  imaging  characteristics 

A  document  may  contain  character,  raster  graphics  and  geometric  graphics  content. 

The  content  architectures  that  may  be  specified  using  the  attribute  "content  architecture  class"  are 
formatted  character,  processable  character,  formatted  processable  character,  formatted  processable 
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raster  graphics  and  formatted  processable  geometric  graphics.  Any  of  these  may  be  specified  as  the 
default  in  the  document  profile. 

6.5.1  Character  content 

6.5.1.1  Introduction 

This  subclause  defines  the  features  that  are  applicable  to  the  character  content  contained  in  a 
document  and  the  presentation  attributes  and  control  functions  that  may  be  used  to  specify  these 
features.  These  features  may  apply  to  basic  logical  and  layout  components  unless  otherwise  indicated. 

The  default  values  for  the  following  features  may  be  specified  in  the  document  profile: 

—  graphic  character  sets; 

—  graphic  character  subrepertoire; 

—  code  extension  announcers; 

—  line  spacing; 

—  character  spacing; 

—  character  path; 

—  line  progression; 

—  character  orientation; 

—  graphic  rendition,  including  the  parameter  values:  default  rendition,  increased  intensity 
(tx)ld),  italicized,  underlined,  crossed-out,  slowly  blinking,  rapidly  blinking,  negative 
image,  positive  image,  primary  font,  1st  alternative  font,  2nd  alternative  font,  3rd 
alternative  font,  4th  alternative  font,  5th  alternative  font.  6th  alternative  font,  7th 
alternative  font.  8th  alternative  font.  9th  alternative  font,  doubly  underlined,  normal 
intensity,  not  italicized,  decreased  intensity,  not  underlined,  not  blinking,  not 
crossed-out; 

—  line  layout  table; 

—  indentation; 

—  alignment; 

—  first  line  offset; 

—  itemization; 

—  widow  size; 

—  orphan  size; 

—  character  fonts; 
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—  kerning  offset; 

—  painwise  kerning; 

—  proportional  line  spacing; 

—  formatting  indicator; 

—  initial  offset. 

The  specification  in  a  document  of  a  non-basic  feature  by  a  presentation  attribute  or  control  function 
shall  be  indicated  in  the  document  profile. 


6.5.1.2  Character  content  architecture 

Processable  and  formatted  processable  form  documents  may  contain  processable,  formatted  or 
formatted  processable  character  content.  Formatted  form  documents  may  contain  formatted  and 
formatted  processable  character  content. 

When  using  character  content,  any  number  of  content  portions  may  be  associated  with  a  basic 
component. 

The  content  information  in  a  content  portion  may  be  absent  This  is  to  allow  the  representation  and 
interchange  of  documents  in  which  parts  of  the  content  may  be  supplied,  for  example,  during 
subsequent  editing. 


6.5.1.3  Character  repertoire 

The  basic  character  repertoire  supported  by  this  profile  is  composed  of  the  94  characters  of  ISO- 
IR6(the  IRV  of  ISO  646  revised  1991)  plus  the  character  space 

Any  other  graphic  character  set  which  is  registered  in  accordance  with  ISO  2375  may  be  designated 
and  invoked  at  any  point  in  the  document  provided  its  use  is  indicated  in  the  document  profile  as  a 
non-basic  value  using  the  character  presentation  feature  "graphic  character  sets".  No  locking  shift 
functions  are  specified  in  this  presentation  feature. 

The  code  extension  techniques  allowed  for  the  designation  and  invocation  of  character  sets  to  the  left 
hand  side  and  right  hand  side  of  the  8-bit  code  table  (GL  and  GR  respectively)  are  defined  in  6.5.1.4. 

Using  these  code  extension  techniques,  the  graphic  character  sets  designated  and/or  invoked  at  the 
beginning  of  a  content  portion  containing  character  content  are  specified  using  the  presentation  attribute 
"graphic  character  sets".  The  character  sets  may  also  be  changed  at  any  point  within  a  content  portion. 

The  default  graphic  character  sets  which  apply  to  the  content  portions  within  a  document  may  be 
specified  in  the  document  profile  using  the  presentation  attribute  "graphic  character  sets". 

If  the  character  set  defined  In  ISO  6937-2  with  or  without  Addendum  1  is  designated  and  Invoked,  then 
the  use  of  any  of  its  subrepertolres  registered  according  to  ISO  7350  may  be  specified  using  the 
presentation  attribute  "graphic  character  subrepertoire".  All  subrepertolres  are  non-basic  and  their  use 
shall  be  indicated  in  the  document  profile.  The  subrepertoire  shall  not  be  changed  within  a  content 
portion. 

NOTE  19  -  The  basic  character  repertoire  supported  by  this  profile  is  not  the  standard  default  value  specified  in 
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[CCITT  Recommendation  T.416  |  ISO  8613-6];  hence  it  may  be  necessary  to  specify  in  the  document  profile  of 
a  particular  document  that  this  is  the  default  value  being  used  for  that  document. 

NOTE  20  -  Revised  CCITT  Recommendations  T.50  and  T.51  and  new  CCITT  Recommendation  T.52  are  under 
preparation.  CCITT  Recommendations  T.50  and  T.51  are  intended  to  be  completely  compatible  with  ISO  646 
revised  1991  (ISO  IR-6)  and  ISO  6937  (under  revision)  respectively. 


6.5.1.4  Code  extension  techniques 

The  code  extension  techniques  specified  in  ISO  2022  may  be  used  subject  to  the  following  restrictions: 

a)  GO  set:  only  IS0-IR6  (the  IRV  of  ISO  646  revised  1991).  IS0-IR2  (the  primary  set  of 
ISO  6937-2),  or  any  other  version  of  ISO  646  (revised  1991)  may  be  designated  as  the 
GO  set;  these  graphic  character  sets  may  only  be  invoked  in  GL; 

b)  G1,  G2,  G3  sets:  no  restrictions  are  placed  on  the  character  sets  that  may  be 
designated  for  these  sets;  these  graphic  character  sets  may  only  be  invoked  in  GR; 

c)  The  locking  and  single  shift  functions  allowed  are  as  follows: 

1)  LSO.  to  invoke  the  GO  set  into  GL; 

2)  LS1R,  to  invoke  the  G1  set  into  GR; 

3)  LS2R,  to  invoke  the  G2  set  into  GR; 

4)  LS3R.  to  invoke  the  G3  set  into  GR; 

5)  SS2,  to  invoke  one  character  from  the  G2  set  into  GL; 

6)  SS3,  to  invoke  one  character  from  the  G3  set  into  GL; 

NOTE  21  -  GL  and  GR  refer  to  the  left  and  right  hand  parts  respectively  of  the  8-bit  code  table. 

d)  When  specifying  the  presentation  attribute  "graphic  character  sets",  it  is  necessary  to 
invoke  character  sets  for  both  GL  and  GR.  Thus  an  allowed  character  set  shall  be 
designated  into  GO  (see  item  (a)  at>ove)  and  invoked  into  GL.  It  is  also  necessary  to 
invoke  a  graphic  character  set  into  GR  which  has  been  designated  into  the  G1 ,  G2  or 
G3  set; 

e)  The  empty  set  shall  be  designated  into  G1  and  invoked  into  GR  if  no  other  specific 
graphic  character  set  is  invoked  into  GR; 

The  code  extension  techniques  allowed  are  illustrated  in  figures  19  and  20. 

The  announcement  and  encoding  of  these  functions  are  to  be  as  specified  in  ISO  2022. 

The  code  extension  techniques  that  are  used  or  may  be  used  in  a  basic  component  shall  be  specified 
by  the  presentation  attribute  "code  extension  announcers."  The  default  code  extension  announcers 
used  throughout  a  document  may  be  specified  in  the  document  profile,  also  using  the  presentation 
attribute  "code  extension  announcers". 

NOTE  22  -  In  accordance  with  [CCITT  Recommendation  T.416  |  ISO  8613-6],  there  is  no  restriction  concerning 
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the  number  of  graphic  character  sets  which  may  be  designated  and/or  invoked  in  the  presentation  attribute 
"graphic  character  sets"  providing  the  restrictions  defined  in  this  subclause  are  applied.    Hence  designation  to 
a  particular  G  set  overrides  a  previous  designation  to  that  set  and  invocation  to  GL  or  GR  overrides  the 
previous  invocation  to  the  GL  or  GR  respectively.  Thus  the  sequential  order  of  designation  and/or  invocation 
sequences  in  the  attribute  "graphic  character  sets"  is  significant. 


[8-bits  code  table] 


_  J  GL 


-J  GR 


Empty  set 


The    IRV  of    ISO  646 
revised  1991  CIS0-IR6:) 


Empty  set 


[ I nvocat  i  on3 


G3 


[ Des 1  gnat  i  on] 


Figure  19  —  Code  extension  features  (basic  case) 


6.5.1.5  Line  spacing 

Any  value  of  line  spacing  may  be  specified.  Values  of  100.  150,  200,  300.  400  and  600  BMUs  are 
basic;  tfie  use  of  any  other  value  in  a  document  is  non-basic  and  shall  be  indicated  in  the  document 
profile. 

The  line  spacing  may  be  specified  at  the  beginning  of  the  content  associated  with  a  basic  component 
using  the  presentation  attribute  "line  spacing".  The  value  may  be  changed  anywhere  within  the  content 
portion  using  the  control  functions  select  line  spacing  (SVS)  and  set  line  spacing  (SLS). 


6.5.1.6  Character  spacing 

Any  value  of  character  spacing  may  be  specified  as  basic  values. 

The  character  spacing  may  be  specified  at  the  beginning  of  the  content  associated  with  a  basic 
component  using  the  attribute  "character  spacing".  The  value  may  be  changed  anywhere  within  a 
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Figure  20  —  Code  extension  features  (all  possible  cases) 


content  portion  using  the  control  functions  select  character  spacing  (SHS)  or  set  character  spacing 
(SCS). 

NOTE  23  -  SHS  parameters  of  0,  1 ,  2,  3  and  4  are  currently  provided.  The  use  of  parameters  5  and  6  may  be 
provided  in  a  future  edition  of  thiis  profile  for  use  with  Chinese  characters. 


6.5.1.7  Character  path  and  line  progression 

Both  horizontal  and  vertical  writing  directions  may  be  used  within  a  document.  In  the  case  of  horizontal 
writing,  the  characters  progress  either  from  left  to  right  or  from  right  to  left  across  the  page  and  the  line 
progression  is  from  the  top  of  the  page  to  the  bottom.  In  the  case  of  vertical  writing,  the  characters 
progress  from  the  top  of  the  page  to  the  bottom  and  the  line  progression  is  from  the  right  to  the  left. 
The  use  of  these  writing  directions  is  restricted  by  the  page  layout  type  used. 

For  body  layout  A,  only  horizontal  writing  may  be  used  in  the  body  area.  Thus  the  character  path  and 
line  progression  is  specified  either  as  0  and  270  degrees  respectively  or  180  and  90  degrees 
respectively. 

For  body  layout  B,  again  only  horizontal  writing  may  be  used  in  the  body  area.  However,  in  this  case 
the  content  in  the  body  area  is  presented  for  viewing  with  the  page  in  landscape  orientation  and  the 
content  in  the  header  and  footer  areas  is  presented  for  viewing  with  the  page  in  portrait  orientation. 
Thus  for  body  layout  B,  in  the  body  area  the  character  path  and  line  progression  is  specified  either  as 
90  and  270  degrees  respectively  or  270  and  90  degrees  respectively. 
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For  body  layout  C,  only  vertical  writing  may  be  used  in  the  body  area.   Thus  the  character  path  and 
line  progression  are  specified  as  270  and  270  degrees  respectively. 

With  regard  to  the  header  and  footer  areas,  if  these  areas  are  placed  at>ove  and  below  the  body  area, 
as  shown  in  figure  1 .  then  only  horizontal  writing  is  allowed  in  these  areas.  Thus,  in  this  case,  the 
character  path  and  line  progression  is  specified  either  as  0  and  270  degrees  respectively  or  180  and  90 
degrees  respectively  (see  figure  2). 

If  the  header  and  footer  areas  are  placed  to  the  left  and  right  of  the  body  area,  then  only  vertical  writing 
Is  allowed  in  these  areas.  Thus,  in  this  case,  the  character  path  and  line  progression  are  specified  as 
270  and  270  degrees  respectively  (see  figure  4). 

All  values  of  character  path  and  line  progression  are  basic.  The  values  of  character  path  and  line 
progression  may  be  specified  at  the  beginning  of  the  content  associated  with  a  basic  component  using 
the  presentation  attributes  "character  path"  and  "line  progression"  respectively.  These  values  cannot  be 
changed  within  a  content  portion. 


6.5.1.8  Character  positioning  controls 

The  active  position  of  a  character  (as  defined  in  [CCITT  Recommendation  T.416  |  ISO  8613-6])  can  t>e 
moved  forward  or  backward  along  the  direction  of  the  line  progression  using  the  control  functions  line 
position  backward  (VPB)  and  line  position  relative  (VPR).  These  control  functions  may  be  specified  in 
all  forms  of  character  content,  and  any  parameter  value  may  be  specified. 

The  active  position  of  a  character  can  be  moved  forward  or  backward  along  the  direction  of  the 
character  path  using  the  control  functions  character  pKDsition  backward  (HPB)  and  character  position 
relative  (HPR). 

The  spacing  between  characters  can  be  increased  or  decreased  using  the  control  functions  set 
additional  character  spacing  (SACS)  and  set  reduced  character  spacing  (SRCS)  respectively.  Also,  the 
width  of  the  character  SPACE  can  be  set  using  the  control  function  set  SPACE  width  (SSW). 

The  control  functions  HPB,  HPR.  SACS.  SRCS  and  SSW  shall  only  be  specified  in  formatted  or 
formatted  processable  character  content;  any  parameter  value  may  be  specified. 


6.5.1.9  Character  orientation 

The  character  orientation  may  be  specified  as  0,  90,  180  or  270  degrees. 

The  orientations  of  0,  90,  and  180  degrees  are  usually  applied  depending  on  whether  vertical  or 
horizontal  writing  is  used.  When  horizontal  writing  is  used,  characters  may  only  be  orientated  at  0 
degrees.  When  vertical  writing  is  used,  characters  may  t>e  orientated  at  90  or  180  degrees. 

All  values  of  character  orientation  are  basic.  The  value  of  the  character  orientation  is  specified  at  the 
beginning  of  the  content  associated  with  a  basic  component  by  the  presentation  attribute  "character 
orientation".  This  value  cannot  be  changed  within  the  content. 


6.5.1.10  Graphic  character  composition 

A  string  of  two  or  more  characters  may  be  combined  to  form  a  single  character  using  the  control 
function  graphic  character  composition  (GCC).  Parameter  values  0,  1  and  2  may  be  specified. 
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6.5.1.11  Emphasis 


The  following  modes  of  emphasising  graphic  characters  may  be  distinguished: 

—  normal  rendition; 

—  normal  intensity; 

—  increased  intensity  (lx>ld); 

—  italicized; 

—  not  italicized; 

—  underlined; 

—  doubly  underlined; 

—  not  underlined; 

—  crossed-out; 

—  not  crossed-out; 

—  slowly  blinking; 

—  rapidly  blinking; 

—  not  blinking; 

—  negative  image; 

—  positive  image. 

All  the  atDOve  modes  of  emphasis  are  basic.  If  no  default  nx)de  is  explicitly  specified  in  the  document 
profile,  then  the  default  mode  is  normal  rendition. 

The  mode  of  emphasis  may  be  specified  at  the  beginning  of  the  content  associated  with  a  basic 
component  using  the  presentation  attribute  "graphic  rendition".  The  mode  may  be  changed  anywhere 
within  the  content  using  the  control  function  set  graphic  rendition  (SGR). 

The  mode  of  emphasis  remains  in  effect  within  the  content  associated  with  a  basic  component  until 
changed  into  a  mutually  exclusive  mode  or  by  the  specification  of  normal  rendition".  Mutually 
exclusive  modes  are  normal/increased/decreased  intensity,  not/slowiy/rapidly  blinking,  italicized/not 
italicized,  underlined/doubly  underlined/not  underlined,  crossed-out/not  crossed-out  and 
positive/negative  image.  One  mode  from  each  mutually  exclusive  set  may  be  in  operation  at  any  point 
in  the  document  content. 

Normal  rendition  cancels  the  effect  of  all  modes  of  emphasis  that  are  currently  in  operation  and 
specifies  that  the  text  shall  be  displayed  in  accordance  with  the  default  rendition  parameters  set  for  the 
presentation  device.  Thus,  for  example,  if  it  is  required  to  ensure  that  the  content  is  not  underlined, 
then  it  is  necessary  to  explicitly  specify  that  underlined  is  not  to  be  used. 
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6.5.1.12  Tabulation 


Tabulation  stop  positions  may  be  specified  at  any  position  along  the  character  path.  Each  stop  is 
specified  by  means  of  the  following: 

a)  The  tabulation  position  relative  to  the  position  of  that  margin  in  the  direction  opposite  to 
the  character  path; 

b)  An  optional  alignment  qualifier  that  specifies  the  type  of  alignment  to  be  used  at  the 
designated  tatxjiation  position.  The  type  may  be  specified  as  one  of  the  following: 

1)  start  aligned; 

2)  end  aligned; 

3)  centred; 

4)  aligned  around. 

These  alignment  qualifiers  are  defined  in  [CCITT  Recommendation  T.416  |  ISO  8613-6].  If  the 
alignment  qualifier  is  not  explicitly  specified,  then  it  is  assumed  that  start  aligned  is  to  be  used. 

Only  one  set  of  tabulation  stops  may  be  specified  to  be  applicable  to  the  content  associated  with  a 
basic  component.  No  limit  is  placed  on  the  number  of  tabulation  stops  that  may  be  specified  within  a 
given  set. 

The  set  of  tabulation  stop  positions  associated  with  the  content  of  a  basic  component  are  specified 
using  the  presentation  attribute  "line  layout  table".  Tabulation  stop  positions  are  invoked  within  the 
content  using  the  control  function  selective  tabulation  (STAB). 

The  tabulation  reference  numbers  used  in  the  STAB  controls  and  associated  Line  Layout  Table  shall  be 
chosen  so  that  in  a  given  Line  Layout  Table,  the  reference  numbers  are  unique,  sequential  in  the 
direction  of  the  character  path,  and  do  not  include  leading  zeroes. 

6.5.1.13  Indentation 

Indentation  is  the  distance  between  the  first  character  on  a  line  of  content  and  the  position  of  the 
margin  that  is  in  the  direction  opposite  to  the  character  path.  Thus  the  value  of  the  indentation 
specified  determines  the  line  home  position  (as  defined  in  (CCITT  Recommendation  T.416  |  ISO 
8613-6]). 

Indentation  is  an  offset  of  that  margin  that  is  in  the  direction  opposite  to  the  character  path.  When  text 
is  formatted,  it  is  intended  to  be  laid  out  between  the  indentation  position  and  the  margin  position  in  the 
direction  of  the  character  path. 

Any  value  of  indentation  may  be  specified  for  basic  logical  components  using  the  presentation  attribute 
"indentation".  The  indentation  value  shall  not  be  changed  within  a  content  portion. 


6.5.1.14  Alignment 

This  feature  is  concerned  with  how  the  first  and  last  characters  on  each  line  of  character  content  is  to 
be  laid  out  during  the  formatting  process. 

The  following  values  of  alignment  may  be  specified  as  basic: 
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—  start  aligned; 


—  end  aligned; 

—  centred; 

—  justified. 


The  semantics  of  these  values  are  as  defined  in  [CCITT  Recommendation  T.416  |  ISO  8613-6]. 

The  presentation  attribute  "alignment"  Is  used  to  specify  the  alignment  that  is  applicable  to  the  content 
associated  with  a  basic  component.  The  alignment  value  cannot  be  changed  within  a  content  portion. 


6.5.1.15  First  line  format 


This  featgre  specifies  how  the  first  line  of  the  content  associated  with  a  basic  component  is  to  be  laid 
out  and  provides  for  the  itemization  of  paragraphs. 

It  allows  the  first  character  in  the  content  to  be  positioned  at  some  point  along  the  character  path 
relative  to  the  indentation  position  (as  specified  in  6.5.1.13).  This  point  may  be  in  the  direction  of  the 
character  path  or  in  the  direction  opposite  to  the  direction  of  the  character  path  relative  to  the 
indentation  position. 

In  addition,  this  feature  provides  for  the  specification  of  an  item  identifier  on  the  first  line.  The  item 
identifier  is  a  string  of  characters  that  precedes  and  is  separated  from  the  remaining  characters  that 
form  the  first  line.  The  control  function  carriage  return  (CR)  is  used  as  the  separator. 

The  features  provided  correspond  to  examples  10.1  to  10.5  shown  in  figure  10  of  [CCITT 
Recommendation  T.416  |  ISO  8613-6]. 


First  line  format  is  specified  by  the  presentation  attributes  "first  line  offset",  "indentation"  and 
"itemization".  Only  those  values  of  the  attributes  which  combine  to  form  the  examples  shown  in  figure 
10  of  [CCITT  Recommendation  T.416  |  ISO  8613-6]  may  be  used. 


6.5.1.16  Widow  and  orphan  sizes 

The  widow  size  specifies  the  minimum  number  of  lines  of  content  that  shall  be  allocated  to  a  following 
frame  or  page  when  the  content  associated  with  a  basic  logical  component  is  laid  out  such  that  it  flows 
over  two  frames  or  pages.  To  accommodate  this,  it  may  be  necessary  to  move  a  number  of  lines  of 
content  from  one  frame  or  page  to  the  next  frame  or  page. 

The  orphan  size  specifies  the  minimum  number  of  lines  of  content  that  shall  be  placed  in  the  current 
frame  or  page  when  the  content  associated  with  a  basic  logical  component  is  split  over  two  frames  or 
pages.  If  this  minimum  cannot  be  accommodated,  then  the  whole  content  shall  be  placed  in  the  next 
frame  or  page. 

Any  value  of  widow  or  orphan  size  may  be  specified  using  the  presentation  attributes  "widow  size"  and 
"orphan  size"  respectively. 

Widow  and  orphan  size  shall  only  be  specified  for  character  content  placed  in  the  body  area  of  pages. 
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6.5.1.17  Fonts 

Any  number  of  fonts  may  be  used  within  a  document   Tfie  fonts  used  in  a  particular  document  are 
specified  in  ttie  document  profile  using  the  attribute  "fonts  list". 

Further  information  concerning  the  specification  of  font  references  in  the  document  profile  is  given  in 
Annex  B.2 

The  fonts  that  may  be  used  within  the  content  associated  with  each  basic  component  are  specified  by 
the  presentation  attribute  "character  fonts".  Up  to  10  fonts  taken  from  the  list  specified  by  the  attribute 
'lorrts  list"  may  be  specified  by  the  attribute  "character  fonts". 

The  font  to  be  used  at  the  start  of  the  content  associated  with  a  basic  component  is  specified  using  the 
attribute  "graphic  rendition".  The  fonts  used  within  the  content  may  be  changed  using  the  control 
function  set  graphic  rendition  (SGR). 

The  document  profile  may  specify,  using  the  attribute  "character  fonts",  a  default  set  of  up  to  10  fonts 
that  are  applicable  to  the  whole  document. 

6.5.1.18  Reverse  character  strings 

Bi-directional  writing  is  supported  by  this  profile.  Hence,  a  string  of  characters  in  a  content  portion 
associated  with  a  basic  component  may  be  specified  to  be  imaged  in  the  reverse  direction  of  the 
immediately  preceding  character  string.  Such  strings  may  be  specified  by  the  control  function  start 
reverse  string  (SRS)  as  defined  in  [CCITT  Recommendation  T.416  |  ISO  8613-6]. 

This  control  function  is  provided  for  cases  in  which  the  text  belongs  to  different  languages  and  the 
character  content  is  written,  for  example,  from  left  to  right  or  from  right  to  left  within  the  same  line  of 
characters,  dependent  upon  the  language  and/or  character  set  being  used. 


6.5.1.19  Parallel  text 

A  string  of  characters  in  a  content  portion  associated  with  a  basic  component  may  be  specified  to  be 
imaged  in  parallel  with  another  character  string.  Typical  example  is  "ruby"  in  the  Japanese  language. 

In  processable  and  formatted  processable  content,  parallel  text  may  be  specified  by  the  control  function 
parallel  text  (PTX). 

In  formatted  content,  the  control  functions  character  position  relative  (HPR),  character  position 
backward  (HPS),  line  position  relative  (VPR)  and  line  position  backward  (VPS)  may  be  used  to  specify 
parallel  text.  These  control  functions  may  also  be  present  in  formatted  processable  content  provided 
that  they  are  contained  within  strings  delimited  by  the  control  functions  start  of  string  (SOS)  and  string 
terminator  (ST). 


6.5.1.20  Kerning  offset 

A  kerning  offset  value  for  the  content  associated  with  a  basic  component  may  be  specified  using  the 
presentation  attribute  "kerning  offset".  It  is  necessary  to  specify  such  a  value  when  certain  fonts  are 
invoked  to  ensure  that  no  part  of  character  images  are  positioned  outside  the  boundary  of  the  available 
area. 
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6.5.1.21  Pairwise  kerning 

Pairwise  kerning  may  be  specified  to  take  place  during  the  layout  process  using  the  attribute  "pairwise 
kerning".  This  process  depends  upon  the  font  used  and  the  modification  applied  to  the  positions  of 
characters  depends  on  the  kerning  information  in  the  font  attributes.  Pairwise  kerning  shall  only  be 
carried  out  if  a  variably  spaced  font  is  used;  the  attribute  "painwise  kerning"  is  ignored  if  a  constant 
spaced  font  is  used. 


6.5.1.22  Proportional  line  spacing 

The  use  of  proportional  line  spacing  may  be  invoked  for  the  content  associated  with  a  basic  logical 
component  using  the  attribute  "proportional  line  spacing".  When  this  invocation  occurs,  the  line  spacing 
between  each  pair  of  consecutive  lines  is  determined  in  an  implementation-defined  way  from  the 
attributes  associated  with  the  fonts  used  within  the  two  lines  and  may  vary  from  one  line  to  the  next. 
This  process  is  application  dependent. 


6.5.1.23  Superscripts  and  subscripts 

Superscripts  and  subscripts  may  be  specified  anywhere  within  the  content  associated  with  a  basic 
component  by  using  the  control  functions  partial  line  up  (PLU)  and  partial  line  down  (PLD).  The  use  of 
these  control  functions  shall  be  in  accordance  with  (CCITT  Recommendation  T.416  |  ISO  8613-6]. 


6.5.1.24  Line  breaks 

The  control  functions  break  permitted  here  (BPH)  and  no  break  here  (NBH)  may  be  inserted  in 
processable  or  formatted  processable  form  character  content  to  indicate  where  line  breaks  may  occur 
or  may  not  occur  respectively  when  the  content  is  laid  out. 


6.5.1.25  Substitution  characters 

The  control  function  SUB  is  provided  to  represent  characters  produced  by  a  local  system  that  cannot  be 
represented  by  a  character  within  a  character  set  supported  by  this  profile. 


6.5.1.26  Initial  point 

The  initial  point  which  is  applicable  to  basic  layout  components  may  be  specified  by  the  attribute  "initial 
offset".  Any  value  may  be  specified. 


6.5.1.27  Use  Of  control  functions 

The  following  is  a  list  of  all  the  control  functions  and  parameter  values  (where  applicable)  that  may  be 
specified  in  character  content: 

SHS  —  select  character  spacing  (allowed  parameter  values:  0,  1,2,  3,  4); 

SCS  —  set  character  spacing  (allowed  parameter  values:  any); 

SVS  —  select  line  spacing  (allowed  parameter  values:  any); 
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SLS  —  set  line  spacing  (allowed  parameter  values:  any); 

SGR  —  set  graptiic  rendition  (allowed  parameter  values:  any); 

STAB—  selective  tabulation  (allowed  parameter  values:  any); 

SRS  —  start  reverse  string  (allowed  parameter  values:  any); 

,      GCC  —  graphic  character  composition  (allowed  parameter  values:  any); 

IGS  —  identify  graphic  subrepertoire  (allowed  parameter  values:  any); 

VP6  —  line  position  backward  (allowed  parameter  values:  any); 

VPR  —  line  position  relative  (allowed  parameter  values:  any); 

HPB  —  character  position  backward  (altowed  parameter  values:  any); 

HPR  —  character  position  relative  (allowed  parameter  values:  any); 

SACS— set  additional  character  spacing  (allowed  parameter  values:  any); 

SRCS— set  reduced  character  spacing  (allowed  parameter  values:  any); 

SSW  —  set  SPACE  width  (allowed  parameter  values:  any); 

PTX  —  parallel  text; 

PLD  —  partial  line  down; 

PLU  —  partial  line  up; 

BPH  —  break  permitted  here; 

NBH  —  no  break  here; 

JFY  —  no  justify; 

SUB  —  substitute  character; 

SP    —  space; 

CR   —  carriage  return; 

LF    —  line  feed; 

SOS  —  Stan  of  string; 

ST    —  string  terminator; 

—  code  extension  control  functions  (see  6.5.1.4). 

The  use  of  all  these  control  functions,  with  the  exception  of  SP.  CR,  LF.  SOS  and  ST.  are  described  in 
various  subclauses  in  6.5.1. 
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6.5.1.28  Formatting  the  content 


The  attribute  'lormatting  indicator"  may  be  specified  for  particular  basic  objects  Vna\  are  conformant  with 
this  profile. 

The  effect  is  to  provide  for  transmission  of  formatted  (or  formatted  processable)  objects  for  which  the 
precise  placement  of  individual  characters  has  been  fully  computed,  and  all  necessary  control  functions 
included.  The  implication  is  that  most  operations  normally  performed  by  the  imaging  processing  in 
handling  formatted  character  text  will  be  rendered  unnecessary. 

To  make  use  of  this,  the  imaging  process  of  the  recipient  shall  operate  with  a  font  containing  metrics 
identical  to  that  used  by  the  originator. 


6.5.2  Raster  graphics  content 


6.5.2.1  Introduction 

This  sut)clause  defines  the  features  that  are  applicable  to  the  raster  graphics  content  contained  In  a 
document.  These  features  may  apply  to  basic  logical  and  layout  components  unless  otherwise 
indicated. 

The  default  values  for  the  following  features  may  be  specified  in  the  document  profile: 

—  type  of  coding; 

—  compression; 

—  pel  spacing; 

—  spacing  ratio; 

—  clipping; 

—  image  dimensions; 

—  pel  path; 

—  line  progression. 

The  specification  in  a  document  of  a  non-basic  feature  by  a  presentation  or  coding  attribute  or  control 
function  shall  be  Indicated  in  the  document  profile. 


6.5.2.2  Raster  graphics  content  architecture 

Only  the  formatted  processable  raster  graphics  content  architecture  class  may  be  used  in  documents 
that  conform  to  this  document  application  profile.  This  type  of  content  may  be  used  in  processable, 
formatted  and  formatted  processable  form  documents. 

When  using  raster  graphics  content,  only  one  content  portion  may  be  associated  with  an  object  or 
object  class. 
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The  content  information  in  a  content  portion  may  be  absent.  This  is  to  allow  the  representation  and 
interchange  of  documents  in  which  parts  of  the  content  may  be  supplied,  for  example,  during 
subsequent  editing. 

Also,  the  scalable  or  fixed  dimension  content  layout  process  may  be  used  when  laying  out  and  imaging 
the  content  depending  upon  the  specification  of  the  presentation  attributes  "pel  spacing"  and  "imaging 
dimensions"  as  described  in  6.5.2.6  and  6.5.2.8.  Both  forms  of  content  layout  processes  may  be  used 
in  a  single  document. 


6.5.2.3  Raster  graphics  encoding  methods 

The  content  may  be  encoded  in  accordance  with  the  encoding  schemes  defined  in  CCITT 
Recommendations  T.4  and  T.6.  In  the  case  of  T.4,  either  the  one-dimensional  or  two  dimensional 
encoding  scheme  may  be  used.  Also  the  'bit-map  encoding'  scheme  defined  in  [CCITT 
Recommendation  T.417  |  ISO  8613-7]  may  be  used.  All  these  forms  of  encoding  may  be  used  in  a 
single  document,  and  all  are  basic.  'Uncompressed'  mode  of  encoding  may  also  be  used,  but  as  a 
non-basic  feature. 

i 

When  using  the  T.4  or  T.6  encoding  method,  the  relationship  between  the  order  of  pels  and  the  order 
of  brts  in  the  octets  in  the  coded  data  stream  shall  be  such  that  the  first  pel  in  the  order  of  bits  is 
allocated  to  the  least  significant  bit  of  an  octet.  In  the  case  of  bit-map  encoding,  the  order  of  encoding 
shall  be  that  the  first  pel  is  allocated  to  the  most  significant  bit  of  an  octet. 

In  a  content  portion,  if  content  information  is  specified,  it  is  required  that  the  coding  attribute  "number 
of  pels  per  line"  is  specified;  the  coding  attribute  "number  of  lines"  may  also  be  specified.  No  restriction 
is  placed  on  the  values  that  may  be  specified  for  these  coding  attributes.  Thus  this  profile  places  no 
restriction  on  the  size  of  the  pel  arrays  that  may  be  used. 

The  type  of  encoding  method  used  is  specified  by  the  attribute  "type  of  coding".  The  use  of  this 
attribute  is  no n- mandatory.  Thus,  if  this  attribute  is  not  specified  for  a  particular  content  portion  and  if 
the  content  architecture  class  specified  corresponds  to  the  formatted  processable  raster  graphics 
content  architecture  class,  then  the  default  encoding  method  is  assumed  to  be  T.6. 


6.5.2.4  Pel  path  and  line  progression 

The  pel  path  direction  may  be  specified  as  0,  90,  180  or  270  degrees  The  line  progression  direction 
may  be  specified  as  90  or  270  degrees. 

A  pel  path  of  0  degrees  and  a  line  progression  of  270  degrees  are  basic  values.  All  other  values  are 
non-basic  and  their  use  shall  be  indicated  in  the  document  profile. 

6.5.2.5  Clipping 

A  sub-region  within  a  pel  array  represented  by  a  content  portion  associated  with  a  basic  component 
may  be  defined  using  the  presentation  attribute  "clipping".  No  restriction  is  placed  on  the  use  of  this 
attribute. 


6.5.2.6  Pel  spacing 

The  pel  spacing  is  the  distance  in  SMUs  between  any  two  pels  on  a  line  when  a  pel  array  is  imaged. 
Any  value  may  be  explicitly  specified  provided  that  the  spacing  between  pels  is  not  less  than  1  SMU. 
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The  pel  spacing  need  not  be  an  integer  value.  Also,  the  value  null'  may  be  specified,  indicating  that 
the  scalable  layout  process  is  to  be  used. 

The  specification  of  the  value  'null'  or  spacings  of  16,  12,  8,  6,  5,  4,  3,  2,  and  1  SMU  between  adjacent 
pels  are  basic.  The  specification  of  any  other  spacing  is  non-basic  and  shall  be  indicated  in  the 
document  profile. 

The  pel  spacing  applicable  to  content  associated  with  basic  logical  components  is  specified  by  the 
presentation  attribute  "pel  spacing". 

NOTE  24  -  The  basic  pel  spacing  values  listed  above  are  equivalent  to  resolutions  of  75,  100,  150,  200,  240, 
300,  400,  600  and  1200  pels  per  25.4mm  respectively  when  the  SMU  is  interpreted  as  1/1200  inch. 

NOTE  25  -  The  attribute  "pel  spacing"  specifies  two  integers,  the  ratio  of  which  determines  the  pels  spacing. 
No  restriction  is  placed  on  the  values  of  these  integers. 


6.5.2.7  Spacing  ratio 

The  spacing  ratio  is  the  ratio  between  the  pel  spacing  and  the  line  spacing  when  a  pel  array  is  imaged. 
This  ratio  is  used  to  determine  the  line  spacing  from  the  pel  spacing  specified. 

No  restrictions  are  placed  on  the  value  of  this  ratio  providing  that  the  resultant  line  spacing  is  not  less 
than  1  SMU.  Also,  the  line  spacing  need  not  be  an  integral  number  of  SMUs.  All  values  are  basic. 

The  default  value  may  be  specified  in  the  document  profile.  If  no  default  value  is  explicitly  specified 
then  the  default  value  is  the  ratio  1:1,  that  is.  the  line  spacing  is  equal  to  the  pel  spacing. 

The  spacing  ratio  applicable  to  the  content  associated  with  a  basic  logical  component  is  specified  by 
the  presentation  attribute  "spacing  ratio". 


6.5.2.8  Image  dimensions 

The  image  dimensions  are  the  constraints  to  be  applied  to  the  size  of  the  image  produced  when  laying 
out  a  pel  array  represented  by  a  content  portion  associated  with  a  basic  logical  component. 

These  constraints  are  specified  for  basic  logical  components  by  the  presentation  attribute  "image 
dimensions".  The  value  of  this  attribute  is  only  taken  into  account  if  the  value  of  the  attribute  "pel 
spacing"  is  null'. 


6.5.3  Geometric  graphics  content 

A  document  may  contain  graphic  images  composed  of  geometric  graphic  content  encoded  as  CGM 
metafiles  in  accordance  with  ISO  8632.  Each  CGM  figure  shall  consist  of  a  single  picture  only.  Each 
CGM  figure  may  specify  its  minimum  dimensions. 


6.6  Miscellaneous  features 
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6.6.1  Resource  documents 

Object  classes  of  the  types  BodyText.  BodyRaster,  BodyGeometric,  CommonText,  CommonRaster. 
CommonGeometric.  Entry  Text.  EntryRaster,  EntryGeometric  and  GenericBlock  may  refer  to 
corresponding  constituent  constraints  in  a  resource  generic-document. 

Tfie  constituent  constraints  in  tfie  resource  document  may  refer  to  content  portions  and  to  layout  and 
presentatbn  styles  that  are  contained  within  the  resource  document.  The  constituent  constraints  listed 
above  are  the  only  ones  that  are  allowed  to  be  referenced  from  another  document  via  the  resource 
attribute:  however,  generic-documents  used  as  resource  documents  may  contain  any  combination  of 
generic  constituent  constraints  which  is  conformant  to  this  document  application  profile. 


6.6.2  External  documents 

In  the  case  of  processable  and  formatted  processable,  the  generic  logical  structure  and  the  generic 
layout  stnjcture,  if  present,  may  be  contained  in  an  external  document.  Note  that  It  is  not  permitted  to 
exchange  one  generic  structure  in  the  interchanged  document  while  referencing  the  other  through  the 
external  document. 


6.6.3  Border 

Borders  may  be  specified  for  all  the  frame  types  defined  in  6.3.5  and  6.3.6  using  the  attribute  "border. 
All  the  features  of  borders  specified  in  [CCITT  Recommendation  T.412  |  ISO  8613-2]  may  be  specified 
as  basic  values.  Borders  may  also  be  specified  in  presentation  styles. 


6.6.4  Unit  scaling 

The  document  profile  attribute  "unit  scaling"  may  be  specified  to  Indicate  a  scaling  factor  that  shall  be 
applied  to  all  attributes  and  control  functions  values  that  specify  absolute  or  relative  positions  and 
dimensions.  This  attribute  specifies  two  integers,  m  and  n.  which  indicate  that  these  values  are  to  be 
interpreted  as  being  equal  to  m/n  ML). 


6.6.5  Application  comments 

Specification  of  the  attribute  "application  comments"  is  mandatory  for  all  object  classes  contained  in  a 
document  that  conforms  to  this  profile.  Specification  and  use  of  this  attribute  is  optional. 

This  attribute  is  structured  so  that  it  contains  two  fields.  The  first  field  is  mandatory  when  the  attribute 
is  specified  and  contains  a  numeric  string  which  uniquely  identifies  the  constituent  constraint  applicable 
to  the  constituent  for  which  the  attribute  is  specified.  This  facilitates  the  processing  of  documents.  A 
list  of  these  identifiers  is  given  in  table  5  and  6. 

NOTE  26- 

a)  The  values  of  the  constituent  constraint  numeric  identifiers  are  not  unique  between  the 
logical  and  layout  structures,  and  therefore  in  order  to  identify  the  constituent  constraint 
applicable  to  a  constituent,  it  is  necessary  to  know  the  structure  of  which  the  constituent 
is  a  pari. 
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b)  For  constituent  constraints  that  correspond  to  each  other  between  the  hierarchically 
related  profiles  to  which  this  profile  belongs,  the  same  constituent  constraint  numeric 
identifier  is  specified. 


The  second  field  is  optional  and  may  contain  any  information  that  is  relevant  to  the  application  or  user. 
The  format  of  the  second  field  is  not  defined  in  this  profile  and  the  interpretation  of  this  field  depends 
upon  a  private  agreement  between  the  originator  and  recipient  of  the  document. 

The  encoding  of  the  attribute  "application  comments"  is  defined  in  8.1.3  and  8.2.3. 


6.6.6  Alternative  representation 

The  content  information  in  a  content  portion  may  be  replaced  by  a  string  of  characters  specified  in  the 
attribute  "Alternative  representation".  This  attribute  may  be  specified  in  content  portions  that  contain 
character,  raster  graphics  or  geometric  graphics  content. 


The  specification  and  use  of  this  attribute  is  optional.  The  string  of  characters  specified  shall  belong  to 
the  character  repertoires  indicated  in  the  document  profile  attribute  "alternative  representation  character 
sets"  (see  6.7.4.3).  If  the  latter  attribute  is  not  explicitly  specified  in  the  document  profile,  then  the 
default  defined  in  (CCITT  Recommendation  T.410  series  |  ISO  8613]  is  assumed.  The  control  functions 
space  (SP),  carriage  return  (CR)  and  line  feed  (LF)  may  also  be  used  within  the  character  string  but  no 
other  control  function  is  allowed;  hence  graphic  character  sets  cannot  be  changed  within  the  alternative 
representation. 


6.6.7  Automatic  numbering  and  referencing  mechanisms 


6.6.7.1  Introduction 


This  profile  provides  general  mechanisms  to  support  the  automatic  numbering  of  various  types  of 
constituents  in  a  document  and  for  referencing  those  numbers  from  other  constituents  in  the  document. 
For  example,  the  numbering  of  segments  (such  as  chapters,  sections  and  annexes),  tables,  figures, 
footnotes,  lists  of  items  and  pages  is  supported. 

I  i  Also  character  strings  may  be  specified  for  various  constituents  and  these  strings  may  be  referenced 

from  other  parts  of  a  document  in  order  to  support  a  general  referencing  mechanism  within  a 
document. 

lj  To  achieve  these  features,  this  profile  provides  the  bindings  listed  in  6.6.7.2.  Subclauses  6.6.7.3  to 

j  6.6.7.11  describe  how  these  bindings  are  used  in  the  automatic  numbering  and  referencing  schemes. 

These  descriptions  are  not  intended  to  restrict  the  use  of  the  bindings  provided  by  this  profile  or  the 
•  I  mechanisms  used  to  achieve  these  numbering  and  referencing  schemes. 


6.6.7.2  Bindings 

The  binding  listed  below  may  be  specified,  unless  othenwise  stated,  on  any  composite  logical 
constituent,  on  basic  logical  constituent  constraints  of  the  types  BodyText,  BodyRaster  and 
BodyGeometric  and  on  layout  constituent  constraints  of  the  types  DocumentLayoutRoot,  PageSet, 
Page,  RectoPage  and  VersoPage. 
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Table  5  —  List  of  number  string  identifiers  for  logical  constituents 


Logical  constituent 

Numeric  s 

identifier 

Docu  mentLog  ical  Root 

0 

Passage 

1 

NumberedSegment 

2 

Number 

3 

Title 

4 

Caption 

c 
9 

Paragraph 

6 

Phrase 

7 

Footnote 

o 
o 

FootnoteNumber 

9 

Footnote  Reference 

10 

FootnoteBody 

1 1 

FootnoteText 

12 

Figure 

13 

BodyText 

14 

Reference 

15 

ReferencedContent 

16 

Body  Raster 

1 7 

BodyGeometric 

18 

CommonContent 

19 

CommonText 

20 

CommonRaster 

21 

CommonGeometric 

22 

Description 

23 

Artwork 

24 

NunnberedList 

25 

UnNumberedList 

26 

DefinitionList 

27 

List  Item 

28 

ListTerm 

29 

Table 

30 

Row 

31 

TableComponent 

32 

RowComponent 

33 

Form 

34 

EntryElement 

35 

EntryGroup 

36 

CommonReference 

37 

CommonNumber 

38 

Currentlnstance 

39 

PageNumber 

40 

Entry  Text 

41 

EntryRaster 

42 

EntryGeometric 

43 

TableNumber 

44 

Groups  of  bindings  have  names  whose  general  form  is  '<name>-<n>*.  The  character  string  <name> 
sen/es  to  identify  a  particular  group  of  bindings  and  <n>  is  a  string  of  characters  that  serves  to  identify 
a  particular  binding.  The  field  <n>  is  a  sequence  of  characters  tal<en  from  the  set  of  characters  '0..9'; 
this  sequence  may  be  of  any  length,  but  shall  consist  of  a  string  representing  an  integer  with  no  leading 
zeroes. 
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Table  6  —  List  of  number  string  identifiers  for  layout  constituents 


uayoui  consiiiueni 

NUmei 

Idenl 

LJucuiiieniLayouinooi 

u 

1 

Page 

2 

RectoPage 

3 

V  fc!  1  bU  r  dy  e 

CompositeHeader 

S> 

FixedCompositeBody 

D 

V  ariauieL'OrnposiieDoay 

7 

ColumnFixed 

o 
O 

UolumnVariaDle 

y 

onaKingooiurnns 

1  u 

oyncnronizGUOoiuiTins 

1  1 

BasicFloat 

1  o 

CompositeFloat 

lo 

DasicL/Oiunin 

1  il 

rooinoieMrea 

1  o 

ArrangedContent  Fixed 

1  D 

ArrangedContent  Variable 

1  7 

Sou  rcedContent  Fixed 

1  Q 

SourcedContentVariable 

1  Q 

(^omposiienxiure  variauie 

or\ 

CompositeFixtureFixed 

oi 
di 

tsasicrixTure 

oo 

CompositeColumn  Fixed 

i.6 

OOmpOSIieV^/OiUMin  Val  laUI6 

OA. 

CompositeCom  mon 

Composite  Artwork 

OP. 

BasicHeader 

dl 

BasicBody 

OQ 
ilb 

GenericBlock 

OQ 

^y 

bpeciticBlocK 

Oft 

30 

FormArea 

J  1 

oomposiierooier 

00 

tjasicrooier 

0»J 

1  ableneader 

34 

EntryGroupArea 

35 

OD 

1  ableLabel 

3/ 

Composite  1  ableLabel 

3o 

Row  Area 

40 

Cell 

41 

SubRowGroup 

42 

SubRow 

43 

TableLabelContent 

44 

FormEntryArea 

45 

Binding  values  may  consist  of  integers  or  character  strings.  In  the  case  of  integers,  any  value  nnay  be 
specified.  In  the  case  of  character  strings,  the  string  may  consist  of  any  of  the  94  characters  of  the  IRV 
of  ISO  646  revised  1991,  IS0-IR6,  plus  the  character  space.  Any  other  character  repertoire  may  be 
used  provided  It  Is  designated  and  invoked  by  the  appropriate  designation  and  invocation  sequences, 
and  Indicated  In  the  document  profile  as  a  non-basic  value.  No  other  control  functions  may  be  used. 
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6.6.7.2.1  Binding  'prefixes-<n>' 

This  binding  specifies  a  character  string  that  is  typically  used  to  specify  a  prefix  string  in  a  character 
string  lepresented  by  another  binding.  Examples  are  prefixes  to  segment,  footnote  and  page  numbers. 


6.6.7.2.2  Binding  'suffixes-<n>' 

This  binding  specifies  a  character  string  that  is  typically  used  to  specify  a  suffix  string  in  a  character 
string  represented  by  another  binding.  Examples  are  suffixes  to  segment,  footnote  and  page  numbers. 


6.6.7.2.3  Binding  'numberstring-<n>' 

This  binding  specifies  a  character  string  that  typically  consists  of  one  or  nrxjre  numerals  and  separators 
that  constitutes,  for  example,  a  segment,  figure,  table,  list  item  or  footnote  number  in  a  document.  An 
example  is  the  string  '3.4.3.6"  which  might  identify  a  sub-section  in  a  document. 


6.6.7.2.4  Binding  'numbers-<n>' 

This  binding  specifies  an  integer  that  is  associated  with  a  particular  constituent.  This  integer  is  typically 
used  to  generate  a  numeral  or  a  sequence  of  numerals,  represented  by  the  binding  ■numberstring-<n>* 
that  identifies,  for  example,  a  particular  segment,  footnote,  table,  figure,  list  item  or  page  within  a 
document. 

6.6.7.2.5  Binding  •separator-<n>' 

This  binding  specifies  a  character  string  that  is  typically  used  to  represent  the  separators  between 
numerals  in  a  string  represented  by  the  binding  'numberstring-<n>'.  An  example  is  the  string  '3. 4.3.6" 
where  the  character "."  forms  the  separator. 


6.6.7.2.6  Binding  'string-<n>' 

This  binding  specifies  a  character  string  that  is  associated  with  a  constituent  and  is  used  to  support  a 
general  referencing  mechanism  with  a  document.  Typically  this  binding  is  used  to  support  the 
referencing  of  character  content  specified  in  one  part  of  the  document  from  another  part  of  the 
document.  For  example,  this  binding  might  be  used  to  carry  the  title  of  a  chapter  or  figure  that  is 
referenced  in  some  other  part  of  the  document. 


6.6.7.2.7  Binding  'PGnum' 

This  binding  specifies  an  integer  that  typically  represents  a  page  number.  This  binding  may  only  be 
specified  on  layout  constituent  constraints  of  the  types  DocumentLayoutRoot,  PageSet,  RectoPage, 
VersoPage  and  Page. 
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6.6.7.2.8  Binding  'fnotenumber' 


This  binding  specifies  an  integer  that  is  specifically  provided  to  represent  the  numbers  that  identify 
footnotes.  This  binding  may  only  be  specified  for  the  logical  constituent  constraints 
DocumentLogicalRoot,  Passage  and  Footnote,  and  is  provided  for  compatibility  with  FOD26. 


6.6.7.2.9  Binding  fnotestring' 

This  binding  specifies  a  character  string  which  is  the  equivalent  of  the  number  represented  by  the 
binding  'fnotenumber'.  This  binding  may  only  be  specified  for  the  logical  constituent  constraint 
Footnote,  and  is  provided  for  compatibility  with  FOD26. 


6.6.7.3  Numbering  of  segments 

The  constituent  Number  contains  a  content  generator  which,  when  evaluated  during  the  layout  process, 
produces  a  character  sthng  that  serves  to  identify  the  NumberedSegment  to  which  the  constituent 
constraint  Number  belongs. 

The  format  of  this  character  string  is  as  follows: 

<pre-str><num-str><suf-str> 

This  format  is  defined  by  a  string  expression  which  is  specified  by  the  macro  SEGMENTNUMBER  (see 
7.3.1).  The  description  below  indicates  how  this  string  is  typically  generated. 

The  fields  <pre-str>  and  <suf-str>  are  optional  prefix  and  suffix  character  strings  respectively  which  may 
be  of  any  length.  These  may  be  predefined  in  the  expression  or  derived  from  bindings  of  the  type 
'prefix-<n>'  and  'suffix-<n>'  respectively  that  are  defined  on  constituents  at  higher  levels  in  the 
document  structure. 

The  field  <num-str>  is  the  segment  identifier  which  has  the  following  general  form; 
<number>[<separator><number>]... 


where  [..]...  indicates  optional  repetition.  That  is,  a  segment  identifier  consists  of  a  single  numeral  or  a 
sequence  of  two  or  more  numerals,  each  of  which  is  separated  by  a  character  string  called  a 
'separator'.  An  example  is  the  string  '7.3.3.1'. 

Segment  identifiers  are  represented  by  the  binding  'numberstring-<n>'.  This  binding  may  be  explicitly 
specified  or  generated  automatically  by  a  string  expression  defined  by  the  macro 
USENUMBERSTRINGS  (see  7.3.1)  which  has  the  general  forni: 

<numberstring-x><separator-y><number-z> 

The  field  <numberstring-x>  is  a  reference  to  the  segment  identifier  (that  is,  another  instance  of  a 
binding  of  the  type  'numberstring-<n>')  that  is  specified  for  the  immediately  superior 
NumberedSegment.  This  allows  hierarchically  structured  numbehng  schemes  to  be  specified.  If  this 
NumberedSegment  does  not  exist,  then  this  field  is  empty  and,  in  this  case,  non-hierarchical. 

The  field  <separator-y>  is  character  string  derived  from  a  binding  of  the  type  'separator-<n>'  specified 
at  some  higher  level  in  the  document  structure.  This  field  may  be  empty. 
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The  field  <number-z>  is  the  number  represented  in  the  form  of  a  character  string  that  is  applicable  to 
the  NumberedSegment  whose  identifier  is  being  constructed.  This  number  may  be  represented  in  the 
form  of  an  Arabic  numeral  string,  upper  or  lower  case  Roman  numeral  string  or  by  upper  or  lower  case 
alphabetic  characters. 

The  integer  value  corresponding  to  the  field  <number-z>  may  be  generated  by  one  of  two  methods. 
The  value  may  be  generated  by  a  ORDINAL  function  within  the  expression  defined  by  the  macro 
USENUf^BERSTRINGS.  Alternatively,  it  may  be  derived  by  a  binding  of  the  type  'number-<n>'  which  is 
specified  for  the  NumberedSegment  whose  identifier  is  being  constructed.  The  binding  'number-<n>'  is 
initialized  at  some  suitable  point  in  the  document  and  is  then  automatically  incremented  on  each 
successive  NumberedSegment.  This  is  achieved  using  an  expression  defined  by  the  macro 
USENUf^BERS  (see  7.3.1). 

The  constructed  binding  'numberstring-<n>'  generated  by  the  macro  USENUMBERSTRINGS  may  then 
be  referred  to  by  a  content  generator  specified  by  the  constituent  Number  to  generate  the  identifier  of 
the  NumberedSegment  as  indicated  earlier  in  this  subclause. 

This  binding  is  also  available  for  constructing  the  segment  identifiers  used  at  lower  levels  of 
NumberedSegment.  This  means  that  a  hierarchical  numbering  scheme  may  be  specified  for  the 
NumberedSegments  at  different  levels  of  the  document  structure. 

The  level  number  shall  be  indicated  using  the  smallest  possible  number  of  characters,  that  is,  there 
shall  be  no  leading  zeroes. 

A  document  may  contain  any  number  of  different  independent  numbering  schemes.  This  is  achieved 
by  setting  the  value  of  bindings  of  the  type  'number-<n>',  ■numberstring-<n>,  ■prefix-<n>'  and  suffix- 
<n>';  and  the  expressions  indicated  above  at  appropriate  points  in  the  document  structure. 

The  atx)ve  mechanism  may  be  used  for  different  purposes;  subsequent  subclauses  illustrate  how  this 
mechanism  is  typically  used  for  the  numbering  of  figures,  tables,  lists  of  items  and  footnotes. 


6.6.7.4  Numbering  of  figures 

The  mechanism  used  for  numbering  figures  is  the  same  as  that  used  for  numbering  segments  (see 
6.6.7.3).  That  is.  the  number  of  a  figure  is  generated  by  a  content  generator  specified  in  the  constituent 
Number  which  is  immediately  subordinate  to  the  given  Figure.  This  content  generator  contains  an 
expression  whose  value  is  defined  by  the  macro  SEGMENTNUf^BER.  The  number  associated  with 
each  figure  may  be  represented  by  a  binding  of  the  type  'number-<n>'  and  a  binding  'numberstring-<n>' 
is  used  to  specify  the  character  string  that  represents  the  figure  number.  The  generation  of  these 
bindings  is  as  described  in  6.6.7.3. 

The  figures  in  a  document  may  be  consecutively  numbered  throughout  the  document  irrespective  of  the 
part  of  the  document  in  which  the  figure  are  contained.  Alternatively,  the  numbers  may  be  linked  to  the 
part  of  the  document  to  which  they  relate;  for  example,  the  figures  in  chapter  3  of  a  document  can  be 
specified  as  3.1,  3.2,  3.3  and  so  on. 


6.6.7.5  Numbering  of  lists 

A  list  of  items  that  are  individually  numbered  is  represented  by  the  logical  constituent  NumberedList. 
Each  item  is  represented  by  a  constituent  constraint  of  the  type  Listltem  and  each  number  belonging  to 
each  item  is  represented  by  a  preceding  constituent  constraint  of  the  type  Number. 
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Number  contains  a  content  generator  which,  when  evaluated,  generates  the  number  belonging  to  the 
subsequent  item.  The  format  of  this  content  generator  is  the  same  as  that  used  for  numbering 
segments  (see  6.6.7.3)  and  is  defined  by  the  macro  SEGMENTNUMBER. 

As  described  in  6.6.7.3,  the  binding  'numberstring-<n>'  is  used  to  represent  the  number  string 
belonging  to  each  item.  In  this  case,  this  binding  is  generated  on  the  constituent  constraint  Numljer 
which  is  referred  to  by  the  content  generator  contained  in  the  same  constituent  constraint.  (Note  that  in 
the  case  of  segment  numbers,  the  binding  'numberstring-<n>'  is  generated  on  the  superior  object.) 


6.6.7.6  Numbering  of  tables 

The  constituent  constraint,  TableNumber,  is  typicaliy  used  to  represent  a  character  string  that 
constitutes  the  number  that  relates  to  a  Table.  This  string  is  laid  out  in  a  TableHeader  frame  by  means 
of  a  SourcedContentFixed  frame.  The  latter  frame  specifies  the  attribute  "logical  source"  which 
indicates  the  instance  of  the  constituent  constraint  CommonContent  that  contains  the  subordinate 
TableNumber  which  specifies  the  required  table  number. 

The  character  string  represented  by  TableNumber  is  generated  by  a  content  generator  which  defines  a 
string  expression  specified  by  the  macro  TABLENUMBER  (see  7.3.1).  The  general  format  of  this 
character  string  is  as  follows: 

<pre-str><num-str><suf-str> 

The  fields  <pre-str>  and  <suf-str>  are  optional  prefix  and  suffix  character  strings  which  are  pre-defined 
in  the  expression  or  are  derived  from  bindings  of  the  types  'prefix-<n>'  and  'suffix-<n>'  respectively  that 
are  specified  for  constituents  at  higher  levels  in  the  document  structure. 

The  field  <num-str>  is  a  character  string  that  represents  the  identifier  of  the  table  being  laid  out.  It  is 
obtained  from  the  binding  'numberstring-<n>'  which  is  specified  for  the  logical  object  of  the  type  Table 
which  is  being  laid  out.  That  is,  the  field  <num-str>  is  derived  from  the  current  instance  of  the 
constituent  constraint  of  the  type  Table. 

The  general  format  of  the  field  <num-str>  and  the  mechanisms  used  to  specify  and  generate  this  field 
are  described  in  6.6.7.3. 

Tables,  like  figures,  may  be  independently  numbered  throughout  a  document,  or  their  numbers  may  be 
linked  to  the  segments  in  which  they  are  contained.  An  example  of  a  table  number  is  the  string  '1.1.5' 
where  '1.1'  is  the  number  of  the  segment  to  which  the  table  belongs,  .'  is  a  separator  and  '5'  is  the 
number  associated  with  the  particular  table. 


6.6.7.7  Footnote  numbering 

The  constituent  constraints  FootnoteReference  and  FootnoteNumber  contain  content  generators  which, 
when  evaluated  during  the  layout  process,  produce  character  strings  that  serve  to  identify  the  Footnote 
to  which  the  constituent  constraints  FootnoteReference  and  FootnoteNumber  are  subordinate. 

The  format  of  this  character  string  is  as  follows: 

<pre-str><num-str><suf-str> 

This  sthng  is  defined  by  a  sthng  expression  specified  by  the  macro  FNNUMBER  (see  7.3.1). 
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The  numbering  mechanism  is  the  same  as  that  used  for  numbering  segments  {see  6.6.7.3).  Thus  the 
fields  <pre-str>  and  <suf-str>  are  optional  prefix  and  suffix  character  strings  respectively  which  may  be 
of  any  length.  These  are  derived  from  bindings  of  the  type  'prefix-<n>'  and  'suffix-<n>'  respectively  that 
are  defined  on  constituents  at  a  higher  level  in  the  document  structure. 

The  field  <num-str>  may  be  derived  by  one  of  three  methods.  It  may  be  represented  by  bindings  of  the 
type  'numberstring-<n>*  which  are  derived  using  an  expression  specified  by  the  macro 
USENUMBERSTRINGS  as  described  in  6.6.7.3.  Alternatively,  it  may  be  derived  from  a  binding  of  the 
type  'fnotestring'  which  is  specified  on  the  constituent  Footnote  to  which  the  constituent  constraints 
FootnoteReference  and  FootnoteNumber  are  sulx)rdinate.  This  field  is  automatically  generated  using 
expressions  defined  by  the  macros  INCFNOTENUMBER  and  FNOTENUMBERSTRING.  The  field 
<num-str>  may  also  be  explicitly  specified;  this  case  is  defined  by  the  macro  FNOTESTRINGLITERAL. 

The  above  mechanisms  allow  footnotes  to  be  numbered  consecutively  throughout  a  document,  or  any 
number  of  independent  footnote  numbering  schemes  may  be  used.  For  example,  the  footnotes 
applicable  to  segments,  figures  and  tables  may  all  be  independently  numbered. 


6.6.7.8  Page  numbering 

The  constituent  constraint  PageNumber  is  specifically  provided  to  represent  common  content  that 
contains  a  page  number  and  that  is  to  be  placed  on  each  successive  page  of  a  document.  A 
mechanism  is  provided  which  allows  the  page  number  to  be  automatically  incremented  on  each 
successive  page  of  a  document. 

The  format  of  the  content  generator  specified  by  the  constituent  PageNumber  is  as  follows: 

<pre-str><num-str><pre-str> 

This  format  is  defined  by  a  string  expression  specified  by  the  macro  PGNUMBER  (see  7.3.1). 

The  fields  <pre-str>  and  <suf-str>  are  optional  prefix  and  suffix  character  strings  respectively  which  may 
be  of  any  length.  These  may  be  explicitly  specified  in  the  expression,  or  they  may  be  derived  from 
bindings  of  the  type  'prefix-<n>'  and  'suffix-<n>*  respectively  that  are  defined  on  constituents  at  a  higher 
level  in  the  document  structure. 

The  field  <num-str>  is  the  page  number.  This  consists  of  a  single  number  derived  from  the  binding 
'number-<n>'  or  'PGnum'  which  is  specified  for  the  current  instance  of  the  frame  or  page  in  which  the 
page  number  is  to  be  laid  out.  A  page  number  may  be  represented  in  the  form  of  Arabic  numeric 
strings,  an  upper  or  lower  case  Roman  numeric  string  or  an  equivalent  upper  or  lower  case  alphabetic 
string. 

The  binding  'number-<n>'  is  initialized  at  the  document  layout  root,  page  set  level  or  a  particular  page 
class  (using  the  macro  INITIALISEBINDINGS  defined  in  7.3.1).  The  binding  PGnum'  is  initialized  at 
the  document  layout  root  or  page  set  level  (using  the  macro  INITIALISEPGNUM  defined  in  7.3.1).  This 
binding  is  automatically  incremented  on  each  successive  page  using  an  expression  specified  by  the 
macro  USEPGNUMBERS  (see  7.3.1).  By  placing  initialization  on  the  layout  root,  rather  than  on  the 
pageset  classes,  the  pagenumbering  may  be  defined  to  be  continued  from  one  pageset  to  the  next. 

The  content  associated  with  logical  object  classes  of  the  type  PageNumber  is  laid  out  in  a  frame  of  one 
of  the  following  types:  BasicHeader,  BasicFooter,  SourcedContentVariable,  SourcedContentFixed  (see 
6.3.6)  using  the  logical  source  mechanism.  Thus  when  the  appropriate  frame  is  being  laid  out,  the  field 
<num-expr>  in  the  content  generator  contained  in  a  logical  object  class  of  the  type  PageNumber  is 
evaluated,  and  this  determines  the  value  of  the  binding  'number-<n>'  or  PGnum  that  is  associated  with 
the  current  page  being  laid  out. 
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Similar  numbering  is  applicable  for  page  sets. 
6.6.7.9  Referenced  content 

ReferencedContent  is  a  constituent  constraint  that  is  provided  to  support  a  general  referencing 
mechanism  within  the  content  of  the  body  part  of  a  document.  This  constituent  constraint,  therefore,  is 
used  to  represent  character  content  that  contains  a  reference  to  content  specified  elsewhere  in  a 
document.  Examples  are  references  to  strings  that  represent  the  numbers  of  segments,  figures,  tables, 
footnotes  and  pages.  Particular  strings  specified  by  'string-<n>'  may  be  referenced. 

This  constituent  constraint  contains  a  content  generator  which,  when  evaluated,  produces  a  character 
string  of  the  following  form: 

<pre-str>  a  sequence  of  <ref-str><suf-str> 

This  content  generator  is  defined  by  a  string  expression  which  is  specified  by  the  macro  REF  (see 
7.3.1).  • 

The  fields  <pre-str>  and  <suf-str>  are  optional  prefix  and  suffix  character  strings  which  may  be  explicitly 
defined  in  the  expression  or  may  be  derived  from  bindings  of  the  type  'prefix-<n>'  and  'suffix-<n>' 
respectively  that  are  defined  on  constituents  at  a  higher  level  in  the  document  structure. 

The  field  <ref-str>  is  a  character  string  that  is  obtained  from  content  specified  on  a  particular  constituent 
in  the  document  by  reference  to  one  of  the  following  bindings;  'numberstring-<n>',  *number-<n>',  'string- 
<n>',  fnotestring'  or  PGnum". 

The  following  referencing  mechanisms  are  permitted  in  this  case: 

—  a  particular  logical  object  is  referenced  for  the  required  binding; 

—  a  particular  logical  object  is  referenced  and  a  search  for  the  required  binding  is  made 
on  the  logical  objects  superior  to  the  referenced  object. 

The  referencing  mechanism  shall  take  into  account  the  constituents  for  which  the  particular  bindings  are 
permitted,  as  defined  in  6.6.7.2. 


6.6.7.10  Common  references 

CommonReference  is  a  constituent  constraint  with  in  the  common  part  of  the  logical  structure  of  a 
document  that  represents  common  character  content  that  may  be  reproduced  in  more  than  one  place  in 
a  document.  This  constituent  constraint  is  specifically  provided  to  represent  content  which  contains  a 
reference  to  content  specified  elsewhere  in  a  document.  This  content  is  specified  by  bindings. 
Examples  are  references  to  character  strings  that  represent  the  numbers  of  segments,  figures,  tables 
and  footnotes  in  a  document. 

This  constituent  constraint  contains  a  content  generator,  the  general  format  of  which  is  the  same  as  the 
content  generator  specified  for  the  constituent  constraint  ReferencedContent  (see  6.6.7.9)  and  content 
may  be  obtained  from  the  following  bindings:  ■numberstring-<n>',  'numbers-<n>',  'string-<n>', 
'fnotestring'  or  'PGnum'. 

This  content  generator  is  defined  by  an  expression  which  is  specified  by  the  macro  COMMONREF. 

The  following  referencing  mechanisms  are  permitted  in  this  case: 
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—  a  current  page  or  frame,  or  a  logical  object  which  is  laid  out  currently  is  referenced  for 
the  required  binding; 

—  a  current  page  or  frame,  or  a  logical  object  which  is  laid  out  currently  is  referenced  and 
a  search  for  the  required  binding  is  made  on  the  constituents  superior  to  a  referenced 
constituent; 

—  a  page  or  frame  into  which  a  particular  logical  object  is  laid  out  is  referenced  for  the 
required  binding; 

—  a  page  or  frame  into  which  a  particular  logical  object  is  laid  out  is  referenced  and  a 
search  for  the  required  binding  is  made  on  the  layout  objects  superior  to  the  referenced 
page  or  frame. 

The  referencing  mechanism  shall  take  into  account  the  constituents  for  which  the  particular  bindings  are 
permitted,  as  defined  in  6.6.7.2. 


6.6.7.1 1  Current  instance  references 

The  constituent  constraint  Currentlnstance,  like  CommonReference,  represents  common  character 
content  that  may  be  reproduced  in  more  than  one  place  in  a  document  when  it  is  laid  out. 

This  constituent  constraint  is  specifically  provided  to  represent  the  current  instance  of  a  character  string 
that  is  to  be  laid  out  in  multiple  places  in  a  document.  A  typical  example  is  the  reproduction  of  a  title  of 
chapter  on  each  page  of  a  document  in  which  that  chapter  is  reproduced. 

The  constituent  constraint  Currentlnstance  contains  a  content  generator,  the  general  format  of  which  is 
the  same  as  the  content  generator  specified  for  the  constituent  constraint  ReferencedContent.  This 
content  generator  is  restricted  to  referencing  content  obtained  from  bindings  of  the  type  'string-<n>' 

The  referencing  mechanism  allows  bindings  of  the  type  'string-<n>'  to  be  referenced  for  the  current 
instance  of  a  logical  constituent  of  a  specified  class  or  the  current  instance  of  a  particular  frame  or 
page. 

The  format  of  this  content  generator  is  defined  by  the  macro  CURRENTINSTANCE  (see  7.3.1). 


6.6.7.12  Common  number  references 

The  constituent  constraint  CommonNumber  represents  common  character  content  that  may  be 
reproduced  in  more  than  one  place  in  a  document  when  it  is  laid  out. 

This  constituent  constraint  is  specifically  provided  to  represent  identifiers  of  other  parts  of  a  document, 
that  is,  character  strings  that  represent  the  numbers  of  segments,  figures  and  tables  within  a  document. 

This  constituent  constraint  contains  a  content  generator,  the  general  format  of  which  is  the  same  as  the 
content  generator  specified  for  the  constituent  constraint  ReferencedContent  (see  6.6.7.9).  This  content 
generator  may  reference  content  specified  by  the  bindings  'numt3erstring-<n>'  and  'numbers-<n>'. 

The  format  of  this  content  generator  is  defined  by  the  macro  COMMONNUMBER  (see  7.3.1). 
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6.6.8  User  readable  comments 


Information  which  is  to  be  interpreted  as  comments  relevant  to  constituents  and  associated  content 
portions  may  be  specified  using  the  attribute  "user  readable  comments".  This  information  is  intended 
for  presentation  to  humans. 

The  information  consists  of  a  stnng  of  characters  which  shall  belong  to  one  of  the  graphic  character 
sets  indicated  in  the  document  profile  attribute  "comments  character  sets"  (see  6.7.4.2).  If  the  latter 
attribute  is  not  explicitly  specified,  then  the  default  defined  in  (CCITT  Recommendation  T.410  series  | 
ISO  8613]  is  assumed.  The  control  functions  space  (SP),  carriage  return  (CR)  and  line  feed  (LF)  and 
code  extension  control  functions  may  also  be  used  within  the  character  string,  but  no  other  control 
functions  are  allowed. 


6.6.9  User  visible  name 

Information  which  may  be  used  to  identify  constituents  within  a  document  may  be  specified  using  the 
attribute  "user  visible  name".  This  information  is  intended  for  presentation  to  humans,  for  example,  to 
assist  in  the  editing  of  documents. 

The  information  consists  of  a  string  of  characters  which  shall  belong  to  one  of  the  graphic  character 
sets  indicated  in  the  document  profile  attribute  "comments  character  sets"  (see  6.7.4.2).  If  the  latter 
attribute  is  not  explicitly  specified,  then  the  default  defined  in  [CCITT  Recommendation  T.410  series  | 
ISO  8613)  is  assumed.  The  control  functions  space  (SP),  carriage  return  (CR),  line  feed  (LF)  and  code 
extension  control  functions  may  also  be  used  within  the  character  string,  but  no  other  control  functions 
are  allowed. 


6.7  Document  management  features 


Information  relating  to  the  document  as  a  whole  is  specified  in  the  document  profile  which  is 
represented  by  the  constituent  DocumentProfile.  This  constituent  shall  be  specified  in  every  document. 

The  information  in  the  document  profile  is  classified  into  the  following  categories; 

a)  document  constituent  information; 

b)  document  identification  information; 

c)  document  default  information; 

d)  non-basic  characteristics  information; 

e)  document  management  information. 

The  information  in  the  document  profile  may  be  of  interest  to  the  user,  or  may  be  used  for  machine 
processing  of  the  document. 

6.7.1  Document  constituent  infomiation 


This  information  specifies  which  constituents  are  used  to  represent  the  document,  including  constituents 
that  are  external  to  the  interchanged  document.  This  information  is  divided  into  three  categories. 
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6.7.1 .1  Presence  of  document  constituents 

This  information  indicates  which  constituents  are  included  in  the  document.  That  is.  this  information 
indicates  whether  or  not  the  document  contains  a  generic  logical  stnjcture,  a  specific  logical  structure,  a 
generic  layout  structure,  a  specific  layout  stnjcture,  layout  styles  and  presentation  styles  (see  note).  It 
is  mandatory  to  specify  this  information  in  the  document  profile. 

NOTE  27  -  If  the  generic  logical  or  layout  structure  is  external  to  the  document  (see  6.7.1.3).  then  it  is  still 
necessary  to  indicate  that  these  structures  are  present  and  form  part  of  the  document. 


6.7.1.2  Resource  document  information 

This  information  consists  of  a  reference  to  a  generic-document  refen-ed  to  as  a  resource  document  (see 
6.6.1).  This  is  specified  by  the  attribute  "resource  document".  If  constituents  in  the  document  contain 
references  to  object  classes  in  a  resource  document,  then  it  is  mandatory  to  specify  this  information  in 
the  document  profile. 


6.7.1.3  External  document  information 

This  information  consists  of  a  reference  to  an  external  document  which  may  consist  of  a  generic  logical 
stnjcture  or  both  the  generic  logical  and  the  generic  layout  structures  (see  6.6.2).  If  such  a  reference  is 
required,  then  it  is  specified  by  the  attribute  "external  document  class"  in  the  document  profile. 


6.7.2  Document  identification  information 

This  information  relates  to  the  identification  of  the  document.  This  information  is  divided  into  six 
categories. 


6.7.2.1  Document  application  profile  information 

This  information  indicates  the  document  application  profile  to  which  the  document  belongs.  It  is 
mandatory  to  specify  this  information  using  the  attribute  "document  application  profile". 

6.7.2.2  Document  architecture  class  information 

This  information  indicates  the  document  architecture  class  to  which  the  document  t>elongs  (see  6.1).  It 
is  mandatory  to  specify  this  information  using  the  attribute  "document  architecture  class". 


6.7.2.3  Content  architecture  classes  Information 

This  information  indicates  the  content  architecture  classes  used  in  the  document  (see  6.5.1.2,  6.5.2.2 
and  6.5.3).  It  is  mandatory  to  specify  this  information  using  the  attribute  "content  architecture  classes". 

6.7.2.4  Interchange  format  class  information 

This  information  indicates  the  interchange  format  class  used  to  represent  the  document  (see  clause  8). 
It  is  mandatory  to  specify  this  information  using  the  attribute  "interchange  format  class". 
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6.7.2.5  ODA  version  information 

This  information  indicates  tfie  [CCITT  Recommendation  |  ISO  standard]  to  wfiicfi  tfie  document 
conforms.  It  also  specifies  a  calendar  date,  whicfi  indicates  tfiat  the  document  conforms  to  the  version 
of  the  {CCITT  Recommendation  |  ISO  standard]  and  any  addenda  that  are  current  on  that  date.  It  is 
mandatory  to  specify  this  information,  using  the  attribute  "ODA  version". 

6.7.2.6  Document  reference 

This  information  serves  to  identify  the  document.  Typically  this  information  is  allocated  to  the  documerrt 
by  the  creator  of  the  document.  The  identifier  may  consist  of  an  ASN.1  object  Identifier  or  a  string  of 
characters.  It  is  mandatory  to  specify  this  Information  using  the  attribute  "document  reference". 

6.7.3  Document  default  information 

This  information  specifies  various  default  values  for  attributes  used  in  the  document.  The  default 
values  that  are  allowed  are  specified  in  the  various  subclauses  of  clause  6.  The  specification  of  this 
information  is  only  required  when  it  is  required  to  specify  a  default  value  which  is  other  than  the 
standard  default  value  specified  in  [CCITT  Recommendation  T.410  series  |  ISO  8613]. 

Default  values  for  the  following  groups  of  attributes  may  be  specified: 

—  document  architecture  attributes; 

—  character  content  attributes; 

—  raster  graphics  attributes; 

—  geometric  graphics  attributes. 

6.7.4  Non-basic  characteristics  information 

This  information  specifies  the  non-basic  attribute  values  specified  in  the  document.  It  Is  mandatory  to 
specify  a  non-basic  attribute  values  in  the  document  profile  when  such  a  value  is  used  In  the  document. 

The  following  types  of  non-basic  attribute  values  may  be  specified: 

—  profile  character  sets; 

—  comments  character  sets; 

—  alternative  representation  character  sets; 

—  page  dimensions; 

—  medium  type; 

—  character  presentation  features; 

—  raster  graphics  presentation  features; 

—  raster  graphics  coding  attributes. 
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NOTE  28  -  In  addition  to  the  above,  layout  paths  and  borders  may  be  specified  for  upwards  compatibility  with 
FOD26. 

Further  information  concerning  document  profile,  comments  and  alternative  representation  character 
sets  is  given  below. 


6.7.4.1  Profile  character  sets 

Some  document  profile  attribute  have  values  consisting  of  character  strings,  for  example,  the  document 
management  attributes.  The  character  sets  used  in  these  character  strings  are  specified  by  the 
document  profile  attribute  "profile  character  sets". 

This  attribute  "profile  character  sets"  specifies  a  code  extension  announcer  and  designations  of 
character  sets,  which  are  subject  to  the  following  restrictions: 

a)  the  code  extension  announcer  shall  be  04/03  when  specified  This  code  extension 
announcer  means  to  use  GO  and  G1  sets  in  an  8-bit  environment  and  also  the 
invocation  of  GO  and  G1  sets  into  GL  and  GR  respectively.  Thus,  in  each  attribute  to 
which  this  attribute  applies,  invocation  shift  functions  are  not  necessary  because  GO 
and  G1  sets  are  implicitly  invoked  by  this  code  extension  announcer. 

b)  GO  set.  only  IS0-IR6  (the  IRV  of  ISO  646  revised  1991),  IS0-IR2  (the  pnmary  set  of 
ISO  6937-2),  or  any  other  version  of  ISO  646  may  be  designated  for  this  set;  these 
graphic  character  sets  are  implicitly  invoked  in  GL. 

c)  G1  set.  no  restrictions  are  placed  on  the  graphic  character  sets  that  may  be  designated 
for  this  set.  These  graphic  character  sets  are  implicitly  invoked  in  GR. 

d)  the  empty  set  shall  be  designated  into  G1  and  invoked  into  GR  if  no  other  specific 
character  set  is  invoked  in  GR. 

If  the  attribute  "profile  character  sets"  is  not  specified,  then  the  default  defined  in  [CCITT 
Recommendation  T  410  series  |  ISO  8613]  is  assumed. 


6.7.4.2  Comments  character  sets 

The  character  sets  assumed  to  have  been  designated  and  optionally  invoked  at  the  beginning  of  the 
character  strings  specified  by  the  attributes  "user  readable  comments"  (see  6.6.8)  and  "user  visible 
name"  (see  6.6.9)  are  specified  using  the  document  profile  attribute  "comments  character  sets". 

It  also  specifies  code  extension  techniques  and  the  graphic  character  sets  which  may  be  used  in  the 
attributes  "user  readable  comments"  and  "user  visible  name". 

If  this  attribute  is  specified,  the  code  extension  techniques  which  may  be  used  in  the  attributes  "user 
readable  comments"  and  "user  visible  name"  shall  be  announced  by  appropriate  code  extension 
announcers.  The  use  of  GO  set  and  GL  shall  always  be  announced.  Other  code  extension  announcers 
are  to  be  specified  according  to  the  requirements  of  a  particular  document. 

Two  kinds  of  code  extension  techniques  are  permitted  for  this  attribute.  One  is  to  GL  and  GR  without 
shift  functions,  and  the  other  is  to  use  various  character  set's  by  shift  functions   The  former  is  rather 
restricted,  but  no  shift  functions  are  necessary  in  the  "user  readable  comments"  and  user  visible 
name". 
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The  same  restrictions  as  in  6.7.4.1  is  applied  in  this  case.  The  latter  permits  various  usages  of 
character  sets,  but  invocations  shall  be  specified  by  shift  functions  in  the  "user  readable  comment"  and 
"user  visible  name".  The  same  restriction  as  in  6.5.4  is  applied  in  this  case. 

All  the  graphic  character  sets  which  may  be  used  in  the  attribute  "user  readable  comments"  and  "user 
visible  name"  should  be  designated  in  the  "comments  character  sets". 

There  are  no  restrictions  concerning  the  number  of  graphic  character  sets  which  are  designated  and/or 
invoked  in  the  "comments  character  sets";  hence  designation  to  the  same  G  set  overrides  the  previous 
G  set. 

If  the  attribute  "comments  character  sets"  is  not  specified,  the  default  defined  in  [CCITT 
Recommendation  T.410  series  |  ISO  8613]  is  assumed. 


6.7.4.3  Alternative  representation  character  sets 

This  attribute  specifies  the  graphic  character  sets  designated  and  invoked  at  the  beginning  of  the 
attribute  "alternative  representation"  other  than  the  standard  default  graphic  character  sets. 

The  restriction  on  profile  character  sets  described  in  6.7.4.1  is  also  applied.  If  this  attribute  is  not 
explicitly  specified  in  the  document  profile,  the  default  defined  in  [CCITT  Recommendation  T.410  series 
I  ISO  8613]  is  assumed. 


6.7.5  Fonts  list 

This  information  specifies  all  the  fonts  (if  any)  used  in  the  document.  It  is  specified  using  the  attribute 
"Fonts  list"  (see  Annex  B.2). 


6.7.6  Document  management  attributes 

Document  management  attributes  contain  information  about  the  content  of  the  document  and  its 
purpose.  Information  relating  to  the  following  may  be  specified: 

—  document  description  (see  note); 

—  dates  and  times; 
i —  originators; 

—  other  user  information; 

—  external  references; 

—  local  file  references; 

—  content  attributes; 

—  security  information. 

The  attributes  that  may  be  used  to  specify  this  information  are  defined  in  [CCITT  Recommendation 
T.414  I  ISO  8613-4]. 
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The  string  of  characters  used  in  the  document  management  attributes  shall  belong  to  the  character  set 
indicated  in  the  document  profile  attribute  "profile  character  sets"  (see  6.7.4.1).  If  the  latter  attribute  is 
not  explicitly  specified  in  the  document  profile,  then  the  default  character  set  is  the  minimum 
subrepenoire  of  ISO  6937-2. 

The  control  functions  space  (SP),  carnage  return  (CR)  and  line  feed  (LF)  may  also  be  used  within  the 
character  strings,  but  no  other  control  functions  are  allowed.  Therefore,  the  graphic  character  set 
cannot  be  changed  in  the  document  management  attributes. 

NOTE  29  -  Tfie  document  description  includes  the  specification  of  the  document  reference  (see  6.7.2.6). 
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7  Specification  of  constituent  constraints 


7.1  introduction 

The  structure  diagrams  illustrating  the  relationships  between  the  constituents  in  the  logical  structures 
are  shown  in  7.1.1.  The  macros  indicated  on  these  diagrams  are  defined  in  7.3.1.  These  macros 
define  the  permissible  values  for  the  attribute  "generator  for  sutx^rdinates"  that  are  applicable  to  the 
constituents,  and  define  the  allowed  structures  that  are  supported  by  this  profile. 

The  structure  diagrams  illustrating  the  layout  structures  are  shown  in  7.1.2.  The  macros  indicated  on 
these  diagrams  are  defined  in  7.4.1. 


7.1.1  Diagrams  of  relationships  of  iogicai  constituents 
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Figure  21  —  DocumentLogicaiRoot,  1st  level 
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Figure  22  —  Dc^cumentLogicalRoot,  2nd  level 
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Figure  23  —  Title,  Paragraph  and  ListTerm 


106 


04 


Body 
Text 


PhraseGFS,  CaptionGFS 
or  Descr  i  pt  i  onGFS 


Phrase 


Footnote 


04 


Reference 


05 


OB 


Figure  24  —  Phrase,  Caption  and  Description 
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Figure  28  —  Table 
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Figure  29  —  Reference 
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Figure  30  —  NumberedList 
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Figure  31  —  UnNumberedList 
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Figure  32  —  DefinitionList 
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Figure  33  —  CommonContent 
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7.1.2  Diagrams  of  relationships  of  layout  constituents 


Page 


01 


Figure  34  —  DocumentLayoutRoot 


Basic 
Body 


Basic 
Header 


Compos  i  te 
Header 


02 


Document 

Layout 

Root 


DocLayRoolGFS 


PageSet 


PageSetGFS 


Recto 
Page 


Verso 
Page 


01 


01 


01  • 


PageGFS 


F  i  xed 
Compos  i  te 
Body 


Var  i  ab I e 
Compos  i  te 
Body 


03 


04 


Compos  i  te 
Footer 


02 


Figure  35  —  Page,  RectoPage  and  VersoPage 
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Figure  37  —  FixedCompositeBody 
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Figure  38  —  VariableCompositeBody 
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Figure  39  —  SnaltingColumns 
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Figure  41  —  CompositeFloat 
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Figure  42  —  CompositeColumnVariabie  and  CompositeColumnFixed 
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Figure  43  —  CompositeFixtureVariable  and  CompositeFixtureFixed 
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Figure  44  —  FormArea  and  EntryGroup 
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7.1.3  Notation 


This  clause  is  written  in  accordance  with  the  Document  Application  Profile  and  Notation  (DAPPN)  of 
(CCITT  Recommendation  T.413  |  ISO  8613-1],  Annex  F.  The  following  clarifications  and  minor 
extensions  apply: 

a)  (Clarification]  The  value  range  definition  for  the  attributes  "subordinates"  and  "imaging- 
order"  specify  the  set  of  object  instances  that  may  occur.  The  ordering  and  number 
(which  may  be  zero)  of  object  instances  for  the  attribute  "subordinates"  shall  be  in 
accordance  with  the  value  of  the  attribute  "generator  for  subordinates"  in  the  respective 
object  class. 

b)  (Clarification]  The  value  "ANY_STRING"  can  include  code  extension  control  functions  as 
well  as  graphic  characters. 

c)  (Extension]  In  order  to  write  the  specification  of  the  usage  of  character  sets  and  code 
extension  control  functions  precisely,  the  following  extensions  are  applied 


2)  <escape-sequence>  is  extended  to  include  shift  functions: 

<escape-sequence>  ::=  ESC  <octet>..  (<invocation-control-function>]; 
<invocation-control-function>  ::=  •LS0TLS1RTLS2RTLS3RTSS2 TSSS"; 

3)  Data  type  specification  for  #ESC  in  content  information  is  extended  as: 

<escape-sequence> . . . 

d)  (Clarification]  When  an  attribute  value  is  specified  by  a  set  of  production  rules,  a  non- 
terminating  symt)ol  which  occurs  first  is  its  start  symt>ol.  Note  that  start  symbols  other 
than  <object-id-expr>,  <string-expr>  and  <construction-expr>  are  used. 

e)  (Extension]  Data  type  specifications  other  than  those  specified  in  the  tables  in  DAPPN 
are  applied  for  some  attributes  within  the  range  that  the  base  standard  permits 

f)  (Extension]  "|"  is  used  in  CASE  SUPERIOR  expressions  in  the  following  format  in  order 

to  shorten  the  text: 

CASE  SUPERIOR  ({const1|const2|...|constn}(aaaa))  OF  (  } 

where  consti,  const2,  .  ,  constn  are  names  of  constituent  constraint,  aaaa  is  a  name  of 
attribute. 

This  expression  is  syntactically  equivalent  to  the  following  expression: 

CASE  SUPERIOR  (consti (aaaa))  OF  {  } 

CASE  SUPERIOR  (const2(aaaa))  OF  {  } 


1)  Following  symbols  are  introduced  to  denote  shift  functions: 


Symbol 

LSO 

LS1R 

LS2R 

LS3R 

SS2 

SS3 


Shift  function 
Locking  shift  zero 
Locking  shift  one  right 
Locking  shift  two  right 
Locking  shift  three  right 
Single  shift  two 
Single  shift  three 


Coded  representation 
00/15 
ESC  07/14 
ESC  07/13 
ESC  07/12 
08/14 
08/15 
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CASE  SUPERIOR  (constn(aaaa))  OF  {  } 


When  CASE  SUPERIOR  is  evaluated,  constituents  are  searched  from  the  immediate  superior 
to  the  root.  Only  the  first  one  which  satisfies  one  of  the  constituent  constraints  consti,  const2, 
....  and  constn  is  selected  and  the  attribute  aaaa  in  it  is  tested. 


7.2  Document  profile  constituent  constraints 


7.2.1  Macro  definitions 

DEFINE(FC.  "ASN.1{2  8  2  6  0}"  --  formatted  character  content  -) 
DEFINE(PC,  •■ASN.1{2  8  2  6  1}"  --  processable  character  content  -) 
DEFINE(FPC.  ■•ASN.1{2  8  2  6  2}"  ~  formatted  processable  character  content  -) 
DEFINE(FPR.  "ASN.1{2  8  2  7  2}"  -  formatted  processable  raster  graphics  content  --) 
DEFINE(FPG,  "ASN.1{2  8  2  8  0}"  -  formatted  processable  geometric  graphics  content  -) 


DEFINE(FDA,  "{ 'formatted'}") 

DEFINE(PDA,  "{processable}") 

DEFINE(FPDA.  "{formatted-processable}") 

DEFINE(PDA-FPDA,  "{'processable  Tformatted-processable'}") 

DEFINE(DAC,  "DocumentProfile  (Document-architecture-class)") 
DEFINE(GLAS,  "DocumentProfile  (Generic-layout-stnjcture)") 
DEFINE(COMPLETE.  "{  complete-generator-set  }") 


DEFINE(BasicPageDimensions, " 

REQ  #horizontal-dimension 

{REQ  #fixed-dimension{<=9240}}, 
REQ  #vertical-dimension 

{REQ  #fixed-dimension{<=12400}} 
I  REQ  #horizontal-dimension 

{REQ  #fixed-dimension{<=12400}}. 
REQ  #vertical-dimension 

{REQ  #fixed-dimension{<=9240}} ") 

Any  size  equal  to  or  smaller  than  CARA  (Common  Assured  Reproduction  Area)  of  ISO  A4  and 
ANSI-A.  Both  Portrait  and  Landscape  may  be  specified.  Note  that  the  above  macro  is  defined 
for  clarification  of  the  specification  and  is  not  used  in  any  other  part  of  this  DAP  specification.  -- 


DEFINE(NonBasicPageDimensions.  " 

REQ  #horizontal-dimension 

{REQ  #fixed-dimension{<=39680}}, 
REQ  #vertical-dimension 

{REQ  #fixed-dimension  {12401. .561 20}} 
|REQ  #horizontal-dimension 

{REQ  #fixed-dimension{9241  ..39680}}, 
REQ  #vertical-dimension 

{REQ  #fixed-dimension  {<=56120}} 

-  up  to  ISO  AO  portrait  - 
I  REQ  #horizontal-dimension 
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{REQ  #fixed-dimension 
REQ  #vei1ical-dimension 

{REQ  #fixed-climension 
|REQ  #horizontal-dimension 

{REQ  #fixed-dimension 
REQ  #vertical-dimension 

{REQ  #fixed-dimension 
--  up  to 
|REQ  #horizontal-dimension 

{REQ  #fixed-dimension 
REQ  #vertical-dimension 

{REQ  #fixed-dimension 
|REQ  #hori2ontal-dimension 

{REQ  #1ixed-dimension 
REQ  #vertical-dimension 

{REQ  #1ixed-dimension 
--  up  to 
|REQ  #horizontal-dimension 

{REQ  #fixed-dimension 
REQ  #vertical-dimension 

{REQ  #fixed-dimension 
|REQ  #horizontal-dimension 

{REQ  #fixed-dimension 
REQ  #veftical-dimension 

{REQ  #fixed-dimension 
--  up  to 
|REQ  #horizontal-dimension 

{REQ  #tixed-dimension 
REQ  #verlical-dimension 

{REQ  #1ixed-dimension 
|REQ  #horizontal-dimension 

{REQ  #1ixed -dimension 
REQ  #vertical-dimension 

{REQ  #fixed-dimension 
--  up  to 
|REQ  #horizontal-dimension 

{REQ  #fixed-dimension 
REQ  #verlical-dimensbn 

{REQ  #fixed-dimension 
|REQ  #horizontal-dimension 

{REQ  #fixed-dimension 
REQ  #vertical -dimension 

{REQ  #fixed-dimension 
--  up  to 


{<=56120}}. 

{9241.. 39680}} 

{12401. .56120}}. 

{<=39680}} 

ISO  AO  landscape  -- 

{<=40800}}, 

{12401. 52800}} 

{9241. .40800}}, 

{<=52800}} 
ANSI-E  portrait  -- 

{<=52800}}. 

{9241.40800}} 

{12401.. 52800}}. 

{<=40800}} 
ANSI-E  landscape 

{<=12141}}. 

{12401  .17196}} 

{9241. .12141}}. 

{<=17196}} 

J  IS  B4(  Japanese  legal)  portrait  - 

{<=17196}}. 

{9241. .12141}} 

{12401. .17196}}. 

{<=12141}} 

J  IS  B4(  Japanese  legal)  landscape 
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DEFINE(PermissiblePageDimensions, " 

REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {<=39680}}. 
REQ  #vertical-dimension 

{REQ  #fixed-dimension  {<=56120}}  --  up  to  ISO  AO  portrait 
I  REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {<=56120}}. 
REQ  #vertical-dimension 

{REQ  #fixed-dimension  {<=39680}}  -  up  to  ISQ  AO  landscape 
|REQ  #horizontal-dlmension 

{REQ  #flxed-dimension  {<=40800}}. 
REQ  #vertical-dimension 

{REQ  #fixed-dimension  {<=52800}}  --  up  to  ANSI-E  portrait  - 
|REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {<=52800}}, 
REQ  #vertical-dimension 

{REQ  #tixed-dimension  {<=40800}}  --  up  to  ANSI-E  landscape 


DEFINE(NominalPageSizes, 


REQ 

#horizontal-dimension 

{7015}, 

REQ 

#horizontal-dimension 

{9920}. 

REQ 

#horizontal-dimension 

{9920}. 

REQ 

#horizontal-dimension 

{14030}. 

REQ 

#horizontal-dimension 

{14030}. 

REQ 

#horizontal-dimension 

{19840}. 

REQ 

#horizontal-dimension 

{19840}. 

REQ 

#horizontal-dimension 

{28060}. 

REQ 

#horizontal-dimension 

{28060}. 

REQ 

#horizontal-dimension 

{39680}. 

REQ 

#horizontal-dimension 

{39680}. 

REQ 

#horizontal-dimension 

{56120}. 

REQ 

#horizontal-dimension 

{10200}, 

REQ 

#tiorizontal-dimension 

{16800}, 

REQ 

#tiorizontal-dimension 

{10200}. 

REQ 

#horizontal-dimension 

{13200}. 

REQ 

#horizontal-dimension 

{13200}. 

REQ  #vertical-dimension  {9920} 

-  ISO  A5  portrait  -- 

REQ  #vertical-dimension  {7015} 

--  ISO  A5  landscape  - 

REQ  #vertical-dimension  {14030} 

-  ISO  A4  portrait  - 

REQ  #vertical-dimension  {9920} 

-  ISO  A4  landscape-- 

REQ  #vertical-dimension  {19840} 

-  ISO  A3  portrait  -- 

REQ  #vertical-dimension  {14030} 

-  ISO  A3  landscape  -- 

REQ  #vertical-dimension{28060} 

-  ISO  A2  portrait  - 

REQ  #vertical-dimension  {19840} 

--  ISO  A2  landscape  -- 

REQ  #vertical-dimensbn  {39680} 

--  ISO  A1  portrait  -- 

REQ  #vertical-dimension  {28060} 

--  ISO  A1  landscape  -- 

REQ  #venical-dimension  {56120} 

-  ISO  AO  portrait  -- 

REQ  #vertical-dimension  {39680} 

--  ISO  AO  landscape  -- 

REQ  #vertical-dimension  {16800} 

--  ANSI  legal  portrait  -- 

REQ  #vertical-dimension  {10200} 

-  ANSI  legal  landscape  - 

REQ  #vertical-dimensbn  {13200} 

--  ANSI-A  portrait  - 

REQ  #vertical-dimension  {10200} 

-  ANSI-A  landscape  - 

REQ  #vertical-dimension  {20400} 

-  ANSI-B  portrait  - 
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1  REQ 

#horizontal-dinnension 

{20400}, 

1  REQ 

#horizontal-climension 

{20400}, 

1  REQ 

#horizontal-climension 

{26400}, 

!  REQ 

#horizontal-dimension 

{26400}, 

1  REQ 

#horizontal-dimension 

{40800}. 

1  REQ 

#horizontal-dimension 

{40800}, 

1  REQ 

#horizontal-dimension 

f  COO  A  Al 

{52800}, 

1  REQ 

#horizontal-dimension 

f  O*^^  A  Al 

{33600}, 

1  REQ 

#horizontal-dimension 

i  X  O  A  A  Al 

{48000}, 

1  REQ 

#horizontal-dimension 

{12141}, 

1  REQ 

#horizontal-dimension 

t  A  "7-4  r\c\ 

{17196}, 

1  REQ 

#horizontal-dimension 

f OCAO I 

{8598}, 

1  REQ 

#horizontal-dimension 

{12141}, 

REQ  #vertical-dimension  {13200} 

--  ANSI-B  landscape  -- 

REQ  #vertical-dimension  {26400} 

-  ANSI-C  portrait  -- 

REQ  #verlical-dimension  {20400} 

--  ANSI-C  landscape  -- 

REQ  #vertical-dimension  {40800} 

--  ANSI-D  portrait  -- 

REQ  #vertical-dimension  {26400} 

--  ANSI-D  landscape  -- 

REQ  #vertical -dimension  {52800} 

-  ANSI-E  portrait  -- 

REQ  #vertical-dimension  {40800} 

-  ANSI-E  landscape  - 

REQ  #vertical-dimension  {48000} 

-  ANSI-F  portrait  - 

REQ  #vertical-dimension  {33600} 

-  ANSI-F  landscape  - 

REQ  #vertical-dimension  {17196} 

-  JIS  B4  (Japanese  legal)  portrait  - 
REQ  #vertical-dimension  {12141} 

-  JIS  B4  (Japanese  legal)  landscape 
REQ  #vertical-dimension  {12141} 

-  JIS  85  (Japanese  letter)  portrait  - 
REQ  #vertical-dimension  {8598} 

-  JIS  85  (Japanese  letter)  landscape- 


DEFINE(GRAPHICRENDmONS,  " 

{'cancelTincreased-intensity'  |  decreased-intensity" 

l  italicised'l  underlined'  I'slowly-blinking' 

I  rapidly-blinking  l  negative-image'l  crossed-out' 

rprimary-fontTfirst-alternative-fonf 

I  second-atternative-fonf  I'third-alternative-fonf 

I'fourth-alternative-fonf  I'titth-alternative-fonf 

rsixth-alternative-tontTseventh-alternative-fonf 

l  eighth-alternative-fonf  I  ninth-alternative-font' 

I'doubly-undertined"  |  normal-intensity"  |  not-italicised' 

rnot-underlined'l'steady  Tpositive-image' 

I  not-crossed-ouf  }. . ") 


Macro  defining  permissible  code  ext 

DEFINE(CDEXTEN.      "ESC  02/00  05/00, 

[ESC  02/00  05/03]  , 
[ESC  02/00  05/05)  , 
(ESC  02/00  05/07]  , 
[ESC  02/00  05/10]  , 
[ESC  02/00  05/11] 


)n  announcers.  Note  that  all  the  values  are  basic.  - 

-  Use  GO  &  LSO  - 

-  Use  G1  &  LS1R  - 

-  Use  G2  &  LS2R  - 

-  Use  G3  &  LS3R  - 

-  Use  G2  &  SS2  - 

-  Use  G3  &  SS3  - 


"  Macro  defining  code  extension  announcers  for  DAP  defaults  -- 
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DEFINE(DAP-DEFAULT-CDEXTEN.  "$CDEXTEN") 


-  Macros  defining  final  character  for  designation 

DEFINE(FCORE.  "04/02      -  A  final  character  designating  ISO-IR  6  (the  IRV  of  ISO  646  revised 

1991.  i.e  ASCII)  --") 

DEFINE(F646,   "        --  A  final  character  designating  any  version  of  ISO  646  except  ISO-IR  6  -") 

DEFINE(F94S.  "       -A  final  character  designating  any  registered  94  single  byte  graphic  character 

set,  optionally  preceded  by  one  or  more  intermediate  characters  as  define  in 
Annex  C  of  ISO  2022  --") 

DEFINE(F94M,   "       -  A  final  character  designating  any  registered  94  multi  byte  graphic  character 

set,  optionally  preceded  by  one  or  more  intermediate  characters  as  define  in 
Annex  C  of  ISO  2022  --") 

DEFINE(F96S,   "       -A  final  character  designating  any  registered  96  single  byte  graphic  character 

set,  optionally  preceded  by  one  or  more  intermediate  characters  as  define  in 
Annex  C  of  ISO  2022  --") 

DEFINE(F96M.  "       -  A  final  character  designating  any  registered  96  multi  byte  graphic  character 

set,  optionally  preceded  by  one  or  more  intermediate  characters  as  define  in 
Annex  C  of  ISO  2022  -") 

DEFINE(FEMPTY.  "07/14     The  empty  set  -") 


-  Macro  defining  a  revision  number  of  a  character  set  - 

DEFINE(REV.  "--  An  octet  between  04/00  and  07/14,  which  represents  a  revision  number  as  defined 
in  ISO  2022.  --") 


"  Macros  defining  designation  sequences  - 

DEFINE(DEG-CORE-G0.         "ESC  02/08  $FCORE") 

-  Designate  94  characters  of  ISO-IR  6  (the  IRV  of  ISO  646  revised  1991)  to  GO  - 

DEFINE(DEG-646-G0,  "ESC  02/08  $F646") 

"  Designate  any  version  of  ISO  646,  except  ISO-IR  6,  to  GO  -- 

DEFINE(DEG-ANY-G1.  "{(ESC  02/06  SREV) 

{  ESC  02/09  $F94S 
|ESC  02/04  02/09  $F94M 
|ESC  02/13  $F96S 
|ESC  02/04  02/13  $F96M}}") 
"  Designate  any  character  set  to  G1  ~ 


DEFINE(DEG-ANY-G2,  "{[ESC  02/06  $REV] 

{  ESC  02/10  $F94S 
I  ESC  02/04  02/10  $F94M 
I  ESC  02/14  $F96S 
I  ESC  02/04  02/14  $F96M}}") 
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--  Designate  any  character  set  to  G2  -- 

DEFINE(DEG-ANY-G3.  "{{ESC  02/06  $REV] 

{  ESC  02/1 1  $F94S 
I  ESC  02/04  02/1 1  $F94M 
I  ESC  02/15  $F96S 
I  ESC  02/04  02/15  $F96M}}") 
--  Designate  any  character  set  to  G3 

DEFINE(DEG-EMPTY-G1 .        "ESC  02/09  $FEMPTY") 
--  Designate  the  empty  set  to  G1  -- 


Macro  defining  permissible  graphic  character  sets.  -- 

DEFINE(PERMIT-GRCHAR,  "{$DEG-CORE-G0  LSO  |$DEG-646-G0  LSO}, 
{{$DEG-ANY-G1  LS1R 
|$DEG-ANY-G2  LS2R 
|$DEG-ANY-G3  LS3R}... 
|$DEG-EMPTY-G1  LSIR}") 


--  Macro  defining  graphic  character  sets  for  DAP  defaults  -- 
DEFINE(DAP-DEFAULT-GRCHAR,  "$PERMIT-GRCHAR") 


Macro  defining  basic  graphic  character  sets.  Note  that  this  macro  is  defined  for  clarification  of 
the  specification  and  is  not  used  in  any  other  part  of  this  DAP  specification.  -- 

DEFINE(BASIC-GRCHAR.       "$DEG-CORE-G0  LSO. 

$DEG-EMPTY-G1  LS1R") 


-  Macro  defining  non-basic  graphic  character  sets  -- 

DEFINE(NON-BASIC-GRCHAR.  "{$DEG-646-G0 

|$DEG-ANY-G1 
|$DEG-ANY-G2 
|$DEG-ANY-G3}...") 


--  Macro  defining  character  sets  used  in  document  profile  attributes  -- 
DEFINE(PROFCHAR.  " 

ESC  02/00  04/03  -  announcement  to  use  GO  and  G1 ,  and  to  invoke  into 

GL  and  GR  respectively,  (no  shift  functions  are 
necessary)-- 

{$DEG-CORE-G0  |  $DEG-646-G0  }  --  designate  GO  -- 
{$DEG-ANY-G1  |  $DEG-EMPTY-G1  }  -  designate  G1  -- 

") 
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-  Macro  defining  comments  character  sets  - 


DEFINE(COMCHAR.  " 

--  in  the  case  to  use  txjth  GL  and  GR  without  shift  functions  -- 

ESC  02/00  04/03  --  announcement  to  use  GO  and  G1,  and  to  invoke  into 

GL  and  GR  respectively,  (no  shift  functions  are 
necessary)-- 

{  $DEG-CORE-G0  |  $DEG-646-G0  }  -  designate  GO  -- 
{  $DEG-ANY-G1  |  $DEG-EMPTY-G1  }  -  designate  G1  -- 

I  -  in  the  case  to  use  various  character  sets  (shift  functions  are  necessary)  -- 
{ESC  02/00  05/00. 
[ESC  02/00  05/03], 
(ESC  02/00  05/05], 
[ESC  02/00  05/07], 
(ESC  02/00  05/10], 
(ESC  02/00  05/11]  } 

{  $DEG-CORE-G0  |  $DEG-646-G0  }     --  designate  GO  - 


announcement 

to 

use 

GO 

and 

LSO  - 

announcement 

to 

use 

G1 

and 

LS1R  -- 

announcement 

to 

use 

G2 

and 

LS2R  -- 

announcement 

to 

use 

G3 

and 

LS3R 

announcement 

to 

use 

G2 

and 

SS2  -- 

announcement 

to 

use 

G3 

and 

SS3  -- 

") 


{{$DEG-ANY-G1 
|$DEG-ANY-G2 
|$DEG-ANY-G3}... 
|$DEG-EMPTY-G1} 


--  designate  G1 
--  designate  G2 
--  designate  G3 


--  Macro  defining  character  sets  used  for  alternative  representation  -- 
DEFINE(ALTCHAR,  "SPROFCHAR") 


7.2.2  Constituent  constraints 


7.2.2.1  DocumentProfile 

{ 

CASE  $DAC  OF  { 

$FDA:  PERM  Generic-layout-structure  {factor-set}, 
PERM  Specific-layout-structure  {present}, 
~  must  be  present  in  the  case  of  complete  document  and  not  present 

in  the  case  of  generic  document 
PERM  Presentation-styles  {  present*} 

$PDA:  PERM  Generic-layout-structure  {'complete-generator-set'}, 
PERM  Generic-logical-structure  {'complete-generator-set' 

I'partial-generator-set'}, 
--  must  be  present  if  there  is  no  external  document  class  reference 
PERM  Specific-logical-structure  {'present'}, 
-  must  be  present  in  case  of  complete  document  and  not  present 

in  the  case  of  generic  document 
PERM  Presentation-styles  {'present'}. 
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PERM  Layout-styles 


{■present} 


$FPDA:  PERM  Generic-layout-structure  { complete-generator-set'}, 

-  must  be  present  if  there  is  no  external  document  class  reference  -- 
PERM  Specific-layout-structure  {'present'}. 

-  must  be  present  in  the  case  of  complete  document  and  not  present 
in  the  case  of  generic  document 

PERM  Generic-logical-structure  {'complete-generator-set' 

I'partial-generator-set'} . 

-  must  t>e  present  if  there  is  no  external  document  class  reference  -- 
PERM  Specific-logical-structure  {'present'}. 

-  must  be  present  in  the  case  of  complete  document  and  not  present 
in  the  case  of  generic  document 

PERM  Presentation-styles  {'present'}. 
PERM  Layout-styles  {present*} 

}. 


PERM  External-document-class 
PERM  Resource-document 


{ANY_VALUE}. 
{ANY_VALUE}. 


PERM  Resources 


{MUL  {REQ  #resource-identifier 

REQ  #resource-object-class-identifier 

}. 


{ANY_VALUE}. 
{ANY_VALUE}} 


document  characteristics  - 


REQ  Document-application-profile 


{--  See  clause  8  for  a  definition  of  the  permitted  values 
for  this  attribute  --}. 


PERM  Document-application-profile-defaults 


CASE  $DAC  OF  { 

$FDA  :  {PERM  #content-architecture-class  {$FC|$FPC}} 

$PDA  :  {PERM  #content-architecture-class  {$FC|$PC|$FPC}} 

$FPDA  :  {PERM  #content-architecture-class  {$FC|$FPC}} 


}. 

PERM  #dimensions 
PERM  #medium-type 


{$PermissiblePageDimensions}. 

{PERM  #nominal-page-size  {$NominalPageSizes}. 
PERM  #side-of-sheet  {ANY_VALUE  }}. 


PERM 

#transparency 

{ANY_VALUE}. 

PERM 

#colour 

{ANY_VALUE}. 

PERM 

#layout-path 

{ANY_VALUE}. 

PERM 

#block-alignment 

{ANY_  VALUE}. 

PERM 

#tx)rder 

{ANY_VALUE}. 
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PERM  #page-position 


{ANY_VALUE}. 


PERM  #type-of-coding 

{ASN.1  {28360} 
IASN.1  {2  83  70} 
IASN..1  {2  8  3  7  1} 
IASN.1  {2  8  3  7  2} 
IASN.1  {2  83  73} 
IASN.1  {2  8380} 

PERM  #character-content-defaults  { 


character  encoding  -- 
T.6  encoding  -- 

T.4  one  dimensional  encoding  -- 
T.4  two  dimensional  encoding  -- 
bitmap  encoding  -- 
geometric  encoding  --}, 


PERM  #alignment 

PERM  #character-fonts 

PERM  #ctiaracter-path 

PERM  #character-spacing 

PERM  #character-orientation 

PERM  #code-extension-announcers 

PERM  #first-line-offset 

PERM  #graptiic-character-sets 

PERM  #graphic-character-subreperto 

PERM  #graphic-rendition 

PERM  #itemisation 

PERM  #kerning-offset 

PERM  #line-layout-table 

PERM  #line-progression 

PERM  #line-spacing 

PERM  #pairwise -kerning 

PERM  #indentation 

PERM  #orphan-size 

PERM  #proportional-line-spacing 

PERM  #widow-size 

PERM  #formattlng-indicator 

PERM  #initial-oftset 


PERM  #raster-graphics-content-defaults  { 
PERM  #pel-path 
PERM  #line-progression 
PERM  #clipping 
PERM  #image-dimensions 
PERM  #pel-spacing 
PERM  #spacing-ratio 
PERM  #compression 


{ANY_VALUE}. 
{ANY_VALUE}. 
{ANY_VALUE}, 
{ANY_VALUE}, 
{ANY_VALUE}. 

{$DAP-DEFAULT-CDEXTEN}. 
{ANY_VALUE}, 
{$DAP-DEFAULT-GRCHAR}. 
ire  {ANY_VALUE}, 
{SGRAPHICRENDITIONS}. 
{ANY_VALUE}, 
{ANY_VALUE}, 
{ANY_VALUE}. 
{ANY_VALUE}, 
{ANY_VALUE}, 
{ANY_VALUE}, 
{ANY_VALUE}, 
{ANY_VALUE}, 
{ANY_VALUE}, 
{ANY_VALUE}, 
{ANY_VALUE}, 
{ANY_VALUE} 


{ANY_VALUE}, 
{ANY_VALUE}. 
{ANY_VALUE}. 
{ANY_VALUE}. 
{ANY_VALUE}. 
{ANY_VALUE}, 
{ANY_VALUE} 


}. 


PERM  #geometric-graphics-content-defaults  {ANY_VALUE} 


REQ  Document-architecture-class  {$FDA|  $PDA  |$FPDA}, 

REQ  Content-architecture-classes  {I$FC].($PC],($FPC].[$FPR],I$FPG]}. 

REQ  Interchange-tormat-class 

REQ  Oda-version 


{ -  See  clause  8  for  the  definition  of  the  permitted  values  for 
this  attribute.  -}, 

{REQ  #standard-or-recommendation     {"ISO  8613"}. 
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REQ  #publication-date 


{"1992-05-01"}), 


"  non  basic  document  characteristics 

PERM  Profile-character-sets  {$PROFCHAR}. 

PERM  Comments-character-sets  {$COMCHAR}, 

PERM  Alternative-representation-character-sets  {$ALTCHAR}, 

PERM  Page-dimensions  {PMUL{$NonBasicPageDimensions}}. 

PERM  Medium-types        {PMUL  {PERM  #nominal-page-size  {$NominalPageSizes}. 

PERM  #side-of-sheet  {'rectoTverso'}}}, 

-  All  values  of  "medium  type"  are  non-basic  - 

PERM  Layout-paths         {{'0-degreesT90-degreesT180-degrees').-  }. 

-  These  values  need  not  to  be  declared,  they  may  be  specified  here  for  upwards  compatibility 
from  FOD26  |  PM-26  -- 

PERM  Borders  {ANY_VALUE}. 

-  Any  values  need  not  to  be  declared,  they  may  t>e  specified  here  for  upwards  compatibility 
from  FOD26  |  PM-26  - 

PERM  Coding-attributes  { 
PERM  #raster-graphics-coding-attributes  { 

PERM  #compression  {'uncompressed'} 
} 

}. 

PERM  Presentation-features  { 
PERM  #character-presentation-features  { 

PERM  #character-orientation  {'90-degrees'}. 

-  This  value  needs  not  to  be  declared,  they  may  be  specified  liere  for  upwards  connpatibility 
from  FOD26  |  PM-26  - 

PMUL  {PERM  #character-path  {'90-degrees  ri80-degrees  r270-degrees'}}. 

-  These  values  need  not  to  be  declared,  they  may  be  specified  here  for  upwards 
compatibility  from  FOD26  |  PM-26  — 

PMUL  {PERM  #character.spacing        {<100  1 100  |  160  |  200}}. 

-  These  values  need  not  to  be  declared,  they  may  be  specified  here  for  upwards 
compatibility  from  FOD26  |  PM-26  -- 

PMUL  {PERM  #graphic-rendition  {'crossed-outTnot-crossed-out'}), 

-  These  values  need  not  to  be  declared,  they  may  be  specified  here  for  upwards 
compatibility  from  FOD26  |  PM-26  - 

PMUL  {PERM  #line-spacing     {ANY_VALUE}  EXCEPT{200.  300,  400}}, 

-  Values  100,150  and  600  need  not  to  be  declared,  they  may  be  specified  here  for 
upwards  compatibility  from  FOD26  |  PM-26  - 

PERM  #line-progression  {'90-degrees'}. 
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}. 


--  This  value  needs  not  to  be  declared,  they  may  be  specified  here  for  upwards 
compatibility  from  FOD26  |  PM-26  -- 

Pf^UL  {PERM  #graphic-character-sets  {$NON-BASIC-GRCHAR}}. 
PMUL  {PERM  #graphic-character-subrepertoire  {ANY_VALUE}} 


PERM  #raster-graphics-presentation-features  { 

PMUL  {PERM  #pel-path  {'QO-degreesTISO-degreesTaTO-degrees'}}. 
PERM  #line-progression  {"SO-degrees  }. 

PMUL  {PERM  #pel-spacing      {ANY_VALUE}EXCEPT{16.  12.  8.  6.  5.  4.  3,  2.  1}}. 
--  Any  value  of  #pel  spaces  is  permitted  as  basic  -- 
--  Basic  values  of  #length  are  multiples  of  #pel  spaces  as  listed 


} 


PMUL  {PERM  #spacing-ratio 

{REQ  #line-spacing-value 
REQ  #pel-spacing-value 


{ANY_VALUE}  EXCEPT  {1}. 
{ANY_VALUE)  EXCEPT  {1}}) 


-  additional  document  characteristics  - 
PERM  Unit-scaling 


{REQ  #unit-scaling-m  {ANY_INTEGER}. 
REQ  #unit-scaling-n  {ANYJNTEGER}}. 


PERM  Fonts-list    {PMUL  {REQ  #font-identifier  {ANY_VALUE}. 

REQ  #font-reference  {ANY_VALUE}} 

}. 


-  document  management  attributes  ~ 

-  document  description  - 
PERM  Title 

PERM  Subject 

PERM  Document-type 

PERM  Abstract 

PERM  Keywords 

REQ  Document-reference 

-  dates  and  times  ~ 
PERM  Document-date-and-time 
PERM  Creation-date-and-time 
PERM  Local-filing-date-and-time 
PERM  Expiry-date-and-time 
PERM  Starl-date-and-time 
PERM  Purge-date-and-time 
PERM  Release-date-and-time 
PERM  Revision-history 


{ANY_STRING}. 

{ANY_STRING}. 

{ANY_STRING}. 

{ANY_STRING}. 

{ANY_STRING...}. 

{ANY_VALUE}. 


{ANY_STRING}. 

{ANY_STRING}. 

{ANY_VALUE}, 

{ANY_STRING}, 

{ANY_STRING}. 

{ANY_STRING}. 

{ANY_STRING}. 

{ANY_VALUE}. 


~  originators  ~ 
PERM  Organizations 
PERM  Preparers 
PERM  Owners 
PERM  Authors 


{ANY_STRING...}, 
{ANY_VALUE). 
{ANY_VALUE}. 
{ANY_VALUE}. 
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--  other  user  information  - 
PERM  Copyright 
PERM  Status 
PERM  User-specific-codes 
PERM  Distribution-list 
PERM  Additional-information 


{ANY_VALUE}. 

{ANY_STRING}, 

{ANY_STRING...}. 

{ANY_VALUE). 

{ANY_VALUE}. 


--  external  references  - 
PERM  References-to-other-documents 
PERM  Superseded-documents 


{ANY_VALUE}. 
{ANY_VALUE}. 


-  local  file  references  - 
PERM  Local-file-references 


{ANY_VALUE}. 


-  content  attributes  - 
PERM  Document-size 
PERM  Number-of-pages 
PERM  Languages 


{ANYJNTEGER}. 
{ANYJNTEGER}. 
{ANY_STRING...}. 


-  security  information  - 
PERM  Authorization 
PERM  Security-classification 
PERM  Access-rights 


{ANY_VALUE}. 

{ANY_STRING}. 

{ANY_STRING...} 


7.3  Logical  constituent  constraints 


7.3.1  Macro  definitions 

-  Defines  any  logical  objects  in  a  specrtic  logical  staicture.  - 
DEFINE(LogicalObjects.  " 

<logical-objects>  ::=  OBJECT_ID_OF(DocumentLogicalRoot) 

I  OBJECT_ID_OF(Passage) 
I  OBJECT_ID_OF(NumberedSegment) 
I  OBJECT_ID_OF(Number) 
I  OBJECT_ID_OF(Title) 
I  OBJECT_ID_OF(Caption) 
I  OBJECT_ID_OF(Paragraph) 
I  OBJECT_ID_OF(Phrase) 
I  OBJECT_ID_OF(Footnote) 
I  OBJECT_ID_OF(FootnoteNumb€r) 
I  OBJECT_ID_OF(FootnoteReference) 
I  OBJECT_ID_OF(FootnoteBody) 
1  OBJECT_ID_OF(FootnoteText) 
I  OBJECT_ID_OF(Figure) 
I  OBJECT_ID_OF(BodyText) 
,  I  OBJECT_ID_OF(Reference) 

I  OBJECT_ID_OF(ReferencedContent) 
I  OBJECT_ID_OF(BodyRaster) 
I  OBJECT_ID_OF(BodyGeometric) 
I  OBJECTJD_OF(Description) 
I  OBJECT_ID_OF(Artwori<) 
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OBJECT_ID_OF(NumberedList) 

OBJECT^  ID  OF(UnNumberedList) 

OBJECT_ID_OF(DefinitionList) 

OBJECT_ID_OF(Listltem) 

OBJECT_ID_OF(ListTerm) 

OBJECT_ID^OF(Table) 

OBJECT_ID^OF(Row) 

OBJECT_ID_OF(TableComponent) 

OBJECT_ID^OF(RowComponent) 

OBJECT_ID_OF(Form) 

OBJECT_ID_OF(EntryElement) 

OBJECT_ID_OF(EntryGroup) 

OBJECT_ID_OF(EntryText) 

OBJECT_ID_OF(EntryRaster) 

OBJECT_ID_OF(EntryGeometric); 


Defines  any  logical  object  classes  other  than  classes  referred  by  logical-source' 
DEFINE{LogicalObjectClasses,  " 

<logical-object-classes>  ::=       OBJECT  CLASS_ID_OF(DocumentLogicalRoot) 

I  OBJECT_CLASS_ID_OF{Passage) 
I  OBJECT_CLASS_ID_OF(NumberedSegment) 
I  OBJECT_CLASS_ID_OF(Number) 
I  OBJECT_CLASS_ID_OF(Title) 
I  OBJECT_CLASS_ID_OF(Caption) 
I  OBJECT_CLASS_ID_OF(Paragraph) 
I  OBJECT_CLASS_ID_OF(Phrase) 
I  OBJECT_CLASS_ID_OF(Footnote) 
I  OBJECT„CLASS__ID_OF(FootnoteNumber) 
I  OBJECT  CLASS_ID_OF(FootnoteReference) 
I  OBJECT__CLASS_ID_OF(FootnoteBody) 
I  OBJECT_CLASS_ID_OF(FootnoteText) 
I  OBJECT_CLASSJD_OF{Figure) 
I  OBJECT_CLASS_ID_OF(BodyText) 
I  OBJECT_CLASS_ID_OF(Reference) 
I  OBJECT_CLASS_ID_OF(ReferencedContent) 
I  OBJECT_CLASS_ID_OF(BodyRaster) 
I  OBJECT_CLASS_ID_OF(BodyGeometric) 
I  OBJECT_CLASS_ID_OF(Descrlption) 
I  OBJECT_CLASS_ID_OF(Artwork) 
I  OBJECT  CLASSJD_OF{NumberedList) 
I  OBJECT_CLASS_ID_OF(UnNumberedList) 
I  OBJECT_CLASS_ID_OF(DefinitionList) 
I  OBJECT_CLASS_ID_OF(Listltem) 
I  OBJECT_CLASS_ID_OF(ListTerm) 
I  OBJECT_CLASS_ID_OF(Table) 
I  OBJECT_CLASS_ID_OF(Row) 
I  OBJECT_CLASS_ID_OF(TableComponent) 
I  OBJECT_CLASS_ID_OF(RowComponent) 
I  OBJECT_CLASS_ID_OF(Form) 
I  OBJECT_CLASS_ID_OF(EntryElement) 
i  OBJECT_CLASS_ID_OF(EntryGroup) 
I  OBJECT_CLASS_ID_OF(EntryText) 
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I  OBJECT_CLASSJD_OF(EntryRaster) 
I  OBJECT_CLASS_ID_OF(EntryGeometric); 


DEFINE(N.  "<n>::={'-'0""|""r"y"'2n"'T1""4"1"''5"1'"'6"n"^^^^ 

any  string  of  characters  from  tfie  set  of  characters:  '0'...'9'  -- 


Defines  the  prefix  binding.  This  binding  may  be  used  to  associate  a  string  literal  with  an  object 
or  object  class.  In  addition,  this  binding  is  used  to  prefix  text  to  another  binding,  such  as  a 
segment  number,  figure  number,  table  number,  footnote  number  or  page  number.  The 
instances  are  differentiated  by  a  suffix  number.  -- 

DEFINE(PREFIX.  " 
<prefix>         ::=  •"*prefix-""<n>; 
$N 


Defines  the  suffix  binding.  This  binding  may  be  used  to  associate  a  string  literal  with  an  object 
or  object  class.  In  addition,  this  binding  is  used  to  suffix  text  to  another  binding,  such  as  a 
segment  number,  figure  number,  table  number,  footnote  number  or  page  number.  The 
instances  are  differentiated  by  a  suffix  number.  - 

DEFINE(SUFFIX. 

<suffix>  :;=  ""suffix-""<n>; 

$N 


Defines  the  separator  binding.  This  binding  is  used  to  provide  a  separator  character  for  a 
hierarchical  form  of  a  segment  number,  figure  number,  table  number,  footnote  number  or  page 
number.  The  instances  are  differentiated  by  a  suffix  number.  ~ 


DEFINE(SEPARATOR.  " 

<separator>     ::=  ""separator-""<n>; 

$N 
") 


Defines  the  general  number  binding.  This  binding  may  be  instanced  for  use  as  the  numeric 
value  for  use  such  as  in  segment  number,  figure  number,  table  number,  list  number,  footnote 
number  or  page  number  bindings.  The  instances  are  differentiated  by  a  suffix  numt)er.  -- 


DEFINE(NUIy/lBER. 

<number>  ::=  *'"number-""<n>; 
$N 

") 


Defines  the  general  number  string  binding.  This  binding  may  be  instanced  for  use  as  the  string 
value  such  as  for  segment  number,  figure  number,  table  number,  list  number,  footnote  number 
or  page  numbers.  The  instances  are  differentiated  by  a  suffix  number.  - 
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DEFINE(NUMBERSTRING, " 
<numberstring>  ::=  ""numberstring-""<n>; 

$N 

") 


Defines  the  general  string  binding.  The  instances  are  differentiated  by  a  suffix  number.  -- 

DEFINE(STRING.  " 

<string>         ::=  ""string-""<n>; 

$N 
") 


Defines  the  names  for  footnote  categories.  The  instances  are  differentiated  by  a  suffix  number. 


DEFINE(FOOTNOTECATEGORY.  " 

<footnotecategory>      ;;=  ""Footnote""[""-""<n>]; 

$N 
") 


DEFINE(INiTIALISEBINDINGS,  " 

REQ 

#binding-name 

{SPREFIX}, 

REQ 

#binding-value 

{ANY  STRING} 

|REQ 

#binding-name 

{$SUFFIX}, 

REQ 

#binding-value 

{ANY  STRING} 

|REQ 

#binding-name 

{$SEPARATOR}. 

REQ 

#binding-value 

{ANY_STRING} 

|REQ 

#binding-name 

{$NUMBER}, 

REQ 

#binding-value 

{ANY  INTEGER} 

|REQ 

#binding-name 

{$NUMBERSTRING}, 

REQ 

#binding-value 

{ANY  STRING} 

|REQ 

#binding-name 

{$STRING}. 

REQ 

#binding-value 

{ANY  STRING} 

Used  to  make  a  simple  or  compound  string  out  of  the  number  bindings. 

DEFINE(USENUf^BERSTRINGS.  " 

REQ  #binding-name  {$NUf^BERSTRlNG}, 

REQ  #binding-value 
{<string-expr>   ;:=       <hierarchic-expr>|<simple-expr>  ; 

<hierarchic-expr>        :;=  B_REF(SUP(CURR-OBJ))(<numbeistring>) 

B_REF(SUP(CURR-OBJ))(<separator>) 
<simple-expr>; 

<simple-expr>  ::=  MK-STR(B_REF(CURR-OBJ)(<number>)) 
I  U-ALPHA{B_REF(CURR-OBJ)(<number>)) 
I  L-ALPHA(B_REF(CURR-OBJ)(<number>)) 
I  U-ROM(B_REF(CURR-OBJH<number>)) 
I  L-ROM(B_REF(CURR-OBJ)(<number>)) 
I  MK-STR(ORD(CURR-OBJ)) 
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I  U-ALPHA(ORD(CURR-OBJ)) 
I  L-ALPHA(ORD(CURR-OBJ)) 
I  U-ROM(ORD(CURR-OBJ)) 
I  L-ROM(ORD(CURR-OBJ)) 
I  ANY_STRING; 

$NUMBERSTRING 
$SEPARATOR 
$NUMBER} 
") 


Used  to  increment  any  of  the  number  bindings.  -- 

DEFINE(USENUMBERS.  " 

REQ  #binding-name  {$NUMBER}. 
REQ  #binding-value 

{<num-expr>  :;=  INC(B_REF(PREC(CURR-OBJ))(<number>)); 

SNUMBER} 
") 

Used  to  initialise/specify  or  manipulate  the  bindings.  The  bindings  defined  by  this  macro  are 
permitted  to; 

any  logical  object  class. 

any  logical  object. 

any  layout  object  class  except  frame  classes  and  block  classes. 


DEFINE(SPECIFYBINDINGS.  " 

$INITIALISEBINDINGS  |  $USENUMBERS  |  $USENUf^BERSTRINGS 

") 


Used  to  initialise  fnotenumber  and  fnotestring  bindings.  -- 

Note  that  footnote  numbering  is  realized  as  a  particular  case  of  the  general  number  binding 
mechanism  supported  by  this  DAP  using  the  bindings  <number>  and  <numberstring>. 
"fnotenumber"  and  "fnotestring"  may  be  used  for  the  compatibility  with  FOD26  |  PM-26.  - 

DEFINE(INITIALISEFNOTE.  " 

REQ  #binding-name  {""fnotenumber""}, 
REQ  #binding-value  {>=0} 

") 


--  Used  to  increment  fnotenumber  binding.  -- 

DEFINE{INCFNOTENUMBER." 

REQ  #binding-name  {""fnotenumber""}, 
REQ  #binding-value 

{<num-expr>  ::=  !NC(B_REF(PREC(CURR-OBJ)){"'1notenumber""));} 

") 
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Used  to  create  a  fnotestring  from  a  fnotenumber  binding. 


DEFINE(FNOTENUMBERSTRING,  " 

REQ  #binding-name  {""fnotestring""}, 
REQ  #binding-value  {<str-expr>::= 

MK-STR(B_REF(CURR-OBJ)rfnotenumber")) 
I  U-ALPHA(B_REF(CURR-OBJ)(""fnotenumber"")) 
I  L-ALPHA(B_REF(CURR-OBJ)(-1notenumber"")) 
I  U-ROM(B_REF(CURR-OBJ)(""fnotenumber')) 
I  L-ROM(B_REF(CURR-OBJ)(""fnotenumber""));} 

") 


Used  to  reset  tfie  footnote  number  string  to  a  string  literal.  Thiis  provides  a  mecfianism  for 
setting  tfie  footnote  number  string  to  something  other  than  a  numeric  value.  -- 

DEFINE(FNOTESTRINGLITERAL,  " 

REQ  #binding-name  {""fnotestring""). 

REQ  #binding-value  {ANY_STRING} 

") 


Used  to  initialise  PGnum  binding.  -- 

Note  that  a  page  numbering  is  realized  as  a  particular  case  of  the  general  number  birxJing 
mechanism  supported  by  this  DAP  using  the  bindings  <number>  and  <numberstrlng>.  "PGnum" 
may  be  used  for  the  compatibility  with  FOD26  |  PM-26.  -- 

DEFINE(INITIALISEPGNUMBER,  " 

REQ  #binding-name  {""PGnum""}, 
REQ  #binding-value  {>=-1} 

") 


Used  to  increment  PGnum  binding.  -- 

DEFINE(USEPGNUf^BERS," 

REQ  #binding-name  {""PGnum""}, 

REQ  #binding-value     {<num-expr>::=  INC(B_REF(PREC(CURR-OBJ))rPGnum""));} 

") 


This  string  expression  is  allowed  in  a  content  generator  for  Number  to  automatically  generate 
text  for  segment  numbers,  figure  numbers  or  list  numbers.  (Note:  B_REF(CURR-OBJ)  is  used 
for  list  numbers.)  -- 

DEFINE(SEGMENTNUI^BER.  " 
<string-expr>   ::=  [<pre-str>]<num-str>[<suf-str>]; 
<num-str>  ::=  B_REF(SUP(CURR-OBJ))(<numberstring>) 

I  B_REF(CURR-OBJ)(<numberstring>); 
<pre-str>  ::=       B_REF(SUP(CURR-OBJ))(<prefix>)  |  ANY_STRING; 

<suf-str>  ::=       B_REF(SUP(CURR-OBJ))(<sutfix>)  |  ANY_STRING; 

$NUMBERSTRING 
$PREFIX 
$SUFFIX 
") 
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This  string  expression  is  allowed  in  a  content  generator  for  TableNumber  to  automatically 
generate  text  for  a  table  numt>er.  -- 


DEFINE(TABLENUMBER.  " 

<string-expr>   ::=  [<pre-str>]<num-str>(<suf-str>]; 
<num-str>       ;:=  B_REF 

(CURR-INST(OBJECT_CLASS_ID_OF(Table),(CURR-OBJ))) 

(<numberstring>); 
<pre-str>        :>  B_REF(SUP 

(CURR-INST(OBJECT_CLASS_ID_OF(Table).(CURR-OBJ)))) 

(<prefix>) 
|ANY_STRING; 
<suf-str>        ::=  B_REF(SUP 

(CURR-INST(OBJECT_CLASSJD_OF(Table).(CURR-OBJ)))) 

(<suffix>) 
I  ANY_STRING; 

$NUMBERSTRING 
SPREFIX 
$SUFFIX 
") 


This  string  expression  is  altowed  in  a  content  generator  for  PageNumber  to  automaticalty 
generate  text  for  a  page  nurrtjer.  -- 

Note  that  a  page  numt)er  may  t>e  generated  either  from  <number>  or  <numberstring>  or  from 
PGnum.  PGnum  is  kept  for  the  compatibility  with  FOD26  |  PM-26.  -- 

DEFINE(PGNUMBER.  " 

<string-expr>   ::=  [<pre-str>]<num-str>[<suf-str>]; 

<pre-str>  ::=  B_REF(SUP(<current-layout-object>))(<prefix>)  |  ANY_STRING; 
<suf-str>        ::=  B_REF(SUP(<current-layout-object>)){<suffix>)  |  ANY_STRING; 


<num-str>       ::=  MK-STR(<numeric-expr>) 
I  U-ALPHA(<numeric-expr>) 
I  L-ALPHA(<numeric-expr>) 
I  U-ROM(<numeric-€xpr>) 
I  L-ROM{<numeric-expr>) 
I  B_REF(SUP(<layout-object-1>))(<numberstring>) 
1  B_REF(<layout-object-2>)(<numberstring>); 


<numeric-expr>    ::=  B_REF(SUP(<layout-object-1>))(<number>) 
I  B_REF(SUP(<layout-object-1  >))(-'PGnum"") 
I  B_REF(<layout-object-2>){<number>) 
I  B_REF(<layout-object-2>)(""PGnum"") ; 


<current-layout-object> 

<layout-object-1> 

<layout-object-2> 

<class-or-type-1> 

<class-or-type-2> 


SPREFIX 


:=  <layout-object-1>  |  <layout-object-2>; 

:=  CURR-INST(<class-or-type-1  >.(CURR-OBJ)); 

:=  CURR-INST(<class-or-type-2>.(CURR-OBJ)); 

:=  'frame*; 

:=  'page* 

I  OBJECT_CLASS_ID_OF(Page) 

I  OBJECT_CLASS_ID_OF(RectoPage) 

I  OBJECT_CLASS_ID_OF(VersoPage); 
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SSUFFIX 
$NUMBER 
$NUMBERSTRING 
') 


This  string  expression  is  allowed  in  a  content  generator  for  FootnoteNumber  and 
FootnoteReference  to  automatically  generate  text  for  a  footnote  number. 
Note  that  a  footnote  number  may  be  generated  either  from  <numberstring>  or  from 
"fnotestring".  "fnotestring"  is  kept  for  the  compatibility  with  FOD26  |  PM-26. 

DEFINE(FNNUMBER.  " 

<string-expr>  ::=  [<pre-str>]<num-str>[<suf-str>]; 

<num-str>  ::=  B_REF(SUP{CURR-OBJ))(<numberstring>) 

I  B_REF(SUP(CURR-OBJ))(""fnotestring"") 

I  ANY_STRING; 

<pre-str>  ::=  B_REF(SUP(CURR-OBJ))(<prefix>) 

I  ANY_STRING; 

<suf-str>  ::=  B_REF(SUP(CURR-OBJ))(<suffix>) 

I  ANY_STRING; 

$NUMBERSTRING 

$PREFIX 

$SUFFIX 


This  string  expression  is  allowed  in  a  content  generator  for  ReferencedContent  to  automatically 
generate  text  for  references  such  as  to  segment  numbers,  table  numbers,  figure  numbers,  list 
numbers,  footnote  numbers  and  <string>  bindings  associated  with  a  referring  (i.e.  a  target) 
logical  object,  or  to  page  numbers,  pageset  numbers  and  <string>  bindings  associated  with  a 
layout  object  in  which  the  referring  logical  object  is  laid  out.  -- 

DEFINE(REF.  " 

<string-expr>  ::=  [<pre-str>]<ref-str>[<suf-str>]; 

These  are  a  prefix  and  a  suffix  of  ReferencedContent  itself,  not  those  of  referring  text.  e.g. 
(See*  and  ')'.  -- 

<pre-str>  ::=  B_REF(SUP(CURR-OBJ))(<prefix>)  |  ANY_STRING; 
<suf-str>         ::=  B_REF(SUP(CURR-OBJ))(<suffix>)  |  ANY_STRING; 


<ref-str>         .:=  {  <ref-numberstring> 
I  <ref-fnotestring> 
I  <ref-pgnum> 
I  <ref-number> 
I  <ref-string> 
I  ANY_STRING  }...  ; 

<ref-numberstring>  ::=  [<pre-str-a>]  <ref-str-a>  (<suf-str-a>]; 
<pre-str-a>  ::=  B_REF(SUP(<target-object-1>))(<prefix>) 

I  B_REF(<target-object>)(<prefix>)  ; 
<suf-str-a>  ::=  B_REF(SUP(<target-object-1>))(<suffix>) 

I  B_REF(<target-object>)(<suffix>)  ; 
<ref-str-a>  ::=  B_REF(SUP(<target-object-1>))(<numberstring>) 

I  B_REF(<target-object>)(<numberstring>); 
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<ref-fnotestring>  ::=  [<pre-str-b>]  <ref-str-b>  [<suf-str-b>]; 
<pre-str-b>  ;:=  B_REF(SUP(<target-logical-object-1>))(<prefix>) 

I  B_REF{<target-logical-object>)(<prefix>)  ; 
<suf-str-b>  ::=  B_REF(SUP(<target-logical-object-1>)){<suffix>) 

I  B_REF(<target-logical-object>)(<suf1ix>)  ; 
<ref-str-b>  ;:=  B_REF(SUP(<target-logical-object-1  >))(""fnotestring"") 

I  B_REF(<target-logical-object>)(""fnotestring""); 

<ref-pgnum>  ::=  (<pre-str-c>]  <ref-str-c>  [<suf-str-c>]; 
<pre-str-c>  ::=  B_REF(SUP(<target-layout-object>))(<prefix>)  ; 
<suf-str-c>  ::=  B_REF{SUP(<target-layout-object>)){<suttix>)  ; 

<ref-str-c>  ::=  MK-STR(B_REF(SUP(<layout-object-1>))rPGnum"")) 
I  U-ALPHA(B_REF(SUP(< layout-object- 1>))(""PGnum"")) 
I  L-ALPHA(B_REF(SUP(<layout-object-1  >))rPGnum"")) 
I  U-ROM(B_REF(SUP(<layout-object-1  >))rPGnum-)) 
I  L-ROM(B_REF(SUP(<layout-object-1>))rPGnum"")) 
I  MK-STR(B_REF(<layout-object-2>)rPGnum"")) 
I  U-ALPHA(B_REF(<!ayout-ob)ect-2>)(""PGnum"")) 
I  L-ALPHA(B_REF(<layout-object-2>)rPGnum"")) 
I  U-ROM(B_REF{<layout-object-2>)rPGnum-)) 
I  L-ROM(B_REF(<layout-object-2>)r'PGnum"")) ; 

<ref-number>  ::=  [<pre-str-cl>]  <ref-str-d>  [<suf-str-d>]; 
<pre-str-d>  ;:=  B_REF(SUP(<target-object-1>))(<prefix>) 

I  B_REF(<target-object>)(<prefix>)  ; 
<suf-str-d>  ;:=  B_REF(SUP{<target-object-1>))(<suffix>) 

I  B_REF(<target-object>)(<suftix>)  ; 
<ref-str-d>  :;=  MK-STR(B_REF{SUP{<target-object-1>))(<number>)) 

I  U-ALPHA(B_REF(SUP(<target-object-1>)){<number>)) 

I  L-ALPHA(B_REF(SUP(<target-object-1  >))(<number>)) 

1  U-ROM(B_REF(SUP(<target-object-1  >))(<number>)) 

I  L-ROM{B_REF(SUP(<target-object-1>))(<number>)) 

I  MK-STR{B_REF(<target-ob)ect>)(<number>)) 

I  U-ALPHA(B_REF(<target-object>)(<number>)) 

I  L-ALPHA(B_REF(<target-object>)(<number>)) 

I  U-ROM{B_REF(<target-object>)(<number>)) 

I  L-ROM(B_REF(<target-object>){<number>)); 

<rel-string>  ::=  [<pre-str-e>]  <ref-str-e>  [<sut-str-e>]; 
<pre-str-e>  ::=  B_REF(SUP(<target-object-1  >))(<prefix>) 

I  B_REF(<target-object>){<prefix>)  ; 
<suf-str-e>  ::=  B_REF(SUP(<target-object-1>)){<suttix>) 

I  B_REF(<target-object>)(<sut1ix>)  ; 
<ref-str-e>  ::=  B_REF(SUP(<target-object-1>))(<string>) 

I  B_REF{<target-object>)(<string>). 

<target-object>  ;;=  <target-logical-object>  |  <target-layout-object>; 
<target-object-1>  :=  <target-logical-object-l>  |  <target-layout-object>; 

<target-logical-object>  ::=  <logical-objects>  |  CURR-INST{<class-or-type-logical>.<logical-objects>); 
<target-logical-object-x>  ::=  <logical-objects>  |  CURR-INST(<class-or-type-logical>,<logical-objects>)); 
<target-logical-object-1  >  ::=  CURR-INST(<class-or-type-logical>,<logical-objects>); 
<class-or-type-logical>  ::=  <logical-object-classes> 

I  'composite-logical-objecf 

I  'basic-logical-object'; 
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<target-layout-object>  ;:=  <layout-object-1>  |  <layout-object-2>; 

<layout-object-1>  ::=  CURR-INST(<class-or-type-layout-1>.<target-logical-object-x>); 

<layout-object-2>  ::=  CURR-INST(<class-or-type-layout-2>.<target-logical-object-x>); 

<class-or-type-layout-1>  :  <class-or-type-layout-1>  ::=  'frame'; 

<class-or-type-layout-2>  ::=  'page' 

I  OBJECT_CLASS_ID_OF(Page) 

I  OBJECT_CLASS_ID_OF(RectoPage) 

I  OBJECT_CLASS_ID_OF{VersoPage); 

$PREFIX 
$SUFFIX 

$NUMBERSTRING 
$NUMBER 
$STRING 
$LogicalObjects 
$LogicalObjectClasses 
") 


This  string  expression  is  allowed  in  a  content  generator  for  CommonReference  to  automatically 
generate  text  for  references  such  as  to  segment  numbers,  table  numbers,  figure  numbers,  list 
numbers,  footnote  numbers  and  <string>  bindings  associated  with  a  logical  object  which  is  laid 
out  in  a  current  layout  object,  or  to  page  numbers,  pageset  numbers  and  <string>  bindings 
associated  with  a  current  or  a  superior  layout  object.  -- 

DEFINE(COMf\^ONREF.  " 
<string-expr>   :;=  [<pre-str>]<ref-str>[<suf-str>]; 

<pre-str>  :.=  B_REF(SUP(<current-layout-object>))(<prefix>)  |  ANY_STRING; 
<suf-str>        ::=  B_REF(SUP(<current-layout-object>))(<suffix>)  |  ANY_STRING; 

<ref-str>         ;:=  {  <ref-numberstring> 
I  <ref-fnotestring> 
I  <ref-pgnum> 
I  <ref-number> 
I  <ref-string> 
I  ANY_STRING    }  ...  ; 

<ref-numberstring>  :;=  [<pre-str-a>]  <ref-str-a>  (<suf-str-a>]; 
<pre-str-a>  ::=  B_REF(SUP(<current-object>))(<prefix>) 

I  B_REF(<current-object>)(<prefix>)  ; 
<suf-str-a>  ::=  B_REF(SUP(<current-object>))(<suffix>) 

I  B_REF(<current-object>)(<suffix>)  ; 
<ref-str-a>  ::=  B_REF(SUP(<current-object>))(<numberstring>) 

I  B_REF(<current-object>)(<numberstring>); 

<ref-fnotestring>  ::=  [<pre-str-b>]  <ref-str-b>  [<suf-str-b>]; 
<pre-str-b>  ::=  B_REF(SUP(<current-logical-object>))(<prefix>) 

I  B_REF(<current-logical-object>)(<prefix>)  ; 
<suf-str-b>  :;=  B_REF(SUP(<current-logical-object>))(<suffix>) 

I  B_REF(<current-logical-object>)(<suffix>)  ; 
<ref-str-b>  ::=  B_REF(SUP(<current-logical-object>))("'1notestring"") 

I  B_REF(<current-logical-object>)(""fnotestring""); 

<ref-pgnum>  :;=  [<pre-str-c>]  <ref-str-c>  [<suf-str-c>]; 
<pre-str-c>  :;=  B_REF{SUP(<current-layout-object>))(<prefix>)  ; 
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<suf-str-c>  ::=  B_REF(SUP(<current-layout-object>))(<suffix>)  ; 
<ref-str-c>  ::=  MK-STR(B_REF(SUP(<layout-object-1>))(""PGnum"")) 

U-ALPHA(B_REF(SUP(<layout-object-1>))(""PGnum-)) 
L-ALPHA(B_REF(SUP(<layout-object-1>))rPGnunfT~)) 
U-ROM(B_REF(SUP(<layout-object-1>))(""PGnum"")) 

L-ROM(B_REF(SUP(<layout-object-1>))rPGnum''")) 
MK-STR(B_REF(<layout-object-2>)(-PGnum"")) 
U-ALPHA(B_REF(<layout-object-2>)(-PGnum"")) 
L-ALPHA(B_REF(<layout-object-2>)rPGnum"")) 

U-ROM(B_REF{<layout-object-2>)rPGnum-)) 
L-ROM(B_REF(<layout-object-2>)(""PGnum'"')); 


<ref-number>  ::=  (<pre-str-d>]  <ref-str-d>  [<suf-str-d>]; 
<pre-str-d>  ::=  B_REF(SUP(<current-object>))(<prefix>) 

I  B_REF(<current-object>)(<prefix>)  ; 
<suf-str-d>  ::=  B_REF(SUP(<current-object>))(<suffix>) 

I  B_REF(<current-object>)(<suffix>)  ; 
<ref-str-d>  ::=  MK-STR(B_REF(SUP(<current-object>))(<numb€r>)) 

U-ALPHA(B_REF(SUP(<current-object>))(<number>)) 
L-ALPHA(B_REF(SUP(<current-object>))(<number>)) 
U-ROM(B_REF(SUP(<current-object>))(<number>)) 
L-ROM(B_REF(SUP(<current-object>))(<number>)) 
MK-STR(B_REF(<current-object>)(<number>)) 
U-ALPHA(B_REF(<current-object>)(<number>)} 
L-ALPHA(B_REF(<current-object>)(<number>)) 
U-ROM(B_REF(<current-object>)(<number>)) 
L-ROM(B_REF(<current-object>)(<number>)); 

<ref-string>  ::=  (<pre-str-e>]  <ref-str-e>  (<sut-str-e>l; 
<pre-str-e>  ::=  B_REF(SUP(<current-object>))(<prefix>) 

I  B_REF(<current-object>)(<prefix>)  ; 
<suf-str-e>  ::=  B_REF(SUP(<current-object>))(<suffix>) 

I  B_REF(<current-object>)(<sutfix>)  ; 
<ref-str-e>  ::=  B_REF(SUP(<current-object>))(<string>) 

I  B_REF(<current-object>)(<string>); 

<current-obiect>  .:=  <current-togical-object>  \  <current-layout-object>; 

<current-logical-object>  ::=  CURR-INST(<class-or-type-k)gical>.(CURR-OBJ)); 
<class-or-type-logical>  ::=  <logical-object-classes> 

I  'composite-logical-object' 

I  'basic-logical-object'; 


<current-layout-object>  ::=       <iayout-object-1>  |  <layout-object-2>; 

<layout-object-1>  ::=  CURR-INST(<class-or-type-layout-1  >,(CURR-OBJ)); 

<layout-object-2>  ::=  CURR-INST(<class-or-type-layout-2>,(CURR-OBJ)); 

<class-or-type-layout-1>  ::=  'frame'; 

<class-or-type-layout-2>  ::=  page' 

I  OBJECT_CLASS_ID_OF(Page} 

I  OBJECT_CLASS_ID_OF(RectoPage) 

I  OBJECT_CLASS_ID_OF(VersoPage); 


SPREFIX 
$SUFFIX 

$NUMBERSTRING 
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$NUMBER 
$STRING 

$LogicalObjectClasses 
••) 


This  string  expression  is  allowed  in  a  content  generator  for  ComnrwnNumber  to  automatically 
generate  text  tor  general  references  to  any  kinds  of  numbers  including  segment  numbers,  table 
numbers,  figure  numbers,  list  numbers,  footnote  numbers,  page  numbers  or  pageset  numt)ers, 
etc.  -- 

DEFINE(COMMONNUMBER,  " 
<string-expr>   ::=  <ref-numberstring> 
I  <ref-number>; 

<ref-numberstring>  ::=  (<pre-str-a>]  <ref-str-a>  [<suf-str-a>]; 
<pre-str-a>  ::=  B_REF(SUP(<current-object>))(<prefix>) 

I  B_REF(<current-object>){<prefix>)  |  ANY_STRING; 
<suf-str-a>  ;:=  B_REF(SUP{<current-object>))(<suffix>) 

I  B_REF(<current-object>)(<suffix>)  |  ANY_STRING; 
<ref-str-a>  ::=  B_REF(SUP(<current-object>))(<numberstring>) 

I  B_REF(<current-object>)(<numberstring>); 

<ref-number>  :;=  (<pre-str-b>]  <ref-str-b>  [<suf-str-b>]; 
<pre-str-b>  ::=  B_REF(SUP(<current-object>))(<prefix>) 

I  B_REF(<current-object>)(<prefix>)  |  ANY_STRING; 
<suf-str-b>  ::=  B_REF(SUP(<current-object>))(<suffix>) 

I  B..REF{<current-object>)(<suffix>)  |  ANY_STRING; 
<ref-str-b>  ::=  Mk-STR(B_REF(SUP(<current-object>))(<number>)) 


I  U-ALPHA(B_REF(SUP(<cun-ent-object>))(<number>)) 
I  L-ALPHA(B_REF(SUP(<current-object>))(<number>)) 
I  U-ROM(B_REF(SUP(<current-object>))(<number>)) 
1  L-ROM(B_REF(SUP(<current-object>))(<number>)) 
I  MK-STR{B_REF(<current-object>)(<number>)) 
I  U-ALPHA(B_REF(<current-object>)(<number>)) 
I  L-ALPHA(B_REF(<current-object>)(<number>)) 
I  U-ROM(B_REF(<current-object>){<number>)) 
I  L-ROM(B_REF(<current-object>)(<number>)); 


<current-object> 


::=  <current-logical-object>  \  <current-Jayout-object>; 


<cu  rrent-logical-object> 
<class-or-type-logical> 


;=  CURR-INST(<class-or-type-logical>,(CURR-OBJ)); 
:=  <logical-object-classes> 

I  composite-logical-objecf 

I  'basic-logical-object'; 


<cun'ent-layout-object> 
<class-or-type-layout> 


:=  CURR-INST(<class-or-type-layout>.(CURR-OBJ)); 
:=  'frame' 
I  'page' 

I  OBJECT_CLASS_ID_OF(Page) 

I  OBJECT_CLASS_ID_OF(RectoPage) 

I  OBJECT_CLASSJD_OF(VersoPage); 


$PREFIX 
SSUFFiX 
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$NUMBERSTRING 
$NUMBER 

$LogicalObjectClasses 

") 


This  string  expression  is  allowed  in  a  content  generator  for  Currentlnstance  to  automatically 
generate  text  for  general  references  to  <string>  bindings  associated  with  a  current  logical  or 
layout  object.  -- 

DEFINE(CURRENTINSTANCE.  " 
<string-expr>   ::=  [<pre-str>]<ref-str>[<suf-str>); 
<pre-str>        ::=  B_REF(SUP(<current-objecl>))(<prefix>) 

I  B_REF(<cun^ent-object>)(<prefix>)  |  ANY_STRING; 
<suf-str>         :;=  B_REF(SUP(<current-object>))(<suffix>) 

I  B_REF(<current-object>)(<suffix>)  |  ANY_STRING; 
<ref-str>         ::=  B_REF(SUP(<current-object>))(<string>) 

I  B_REF(<current-object>)(<string>); 

<current-object>         :.=  <current-logical-object>  |  <current-layout-object>; 

<cun^ent-logical-object>  ::=  CURR-INST(<class-or-type-logical>.(CURR-OBJ)); 

<class-or-type-logical>  ;:=  <logical-object-classes> 

I  'composite-logical-object' 

I  'basic-logical-object'; 

<cun^ent-layout-object>  ::=  CURR-INST(<class-or-type-layout>.(CURR-OBJ)); 

<class-or-type-layout>  ::=  'frame' 

I  'page' 

I  OBJECT_CLASS_ID_OF(Page) 

I  OBJECT_CLASSJD_OF(RectoPage) 

I  OBJECT_CLASSJD_OF(VersoPage); 

$PREFIX 
SSUFFIX 
$STRING 

SLogicalObjectClasses 
") 


This  string  expression  is  allowed  in  a  content  generator  for  GenericBlock  to  automatically 
generate  text  for  general  references  to  bindings  associated  with  a  current  layout  object.  - 

DEFINE(GENERICBLOCKREF,  " 
<string-expr>    ::=  [<pre-str>]<ref-str>(<suf-str>]; 

<pre-str>  ::=  B_REF(SUP(CURR-OBJ))(<prefix>)  |  ANY_STRING; 
<suf-str>         ::=  B_REF(SUP(CURR-OBJ))(<suffix>)  |  ANY_STRING; 

<ref-str>         ::=  MK-STR(B_REF(SUP(CURR-OBJ))(<number>)) 
I  U-ALPHA(B_REF(SUP(CURR-OBJ)){<number>)) 
I  L-ALPHA(B_REF(SUP(CURR-OBJ))(<number>)) 
I  U-ROM(B_REF(SUP(CURR-OBJ))(<number>)) 
I  L-ROM(B_REF(SUP(CURR-OBJ))(<number>)) 
I  MK-STR(B_REF(SUP(CURR-OBJ))rPGnum"")) 
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I  U-ALPHA(B_REF(SUP(CURR-OBJ))rPGnum-')) 
I  L-ALPHA(B_REF(SUP(CURR-OBJ))(""PGnum-)) 
I  U-ROM(B_REF(SUP(CURR-OBJ))rPGnum"")) 
I  L-ROM(B_REF(SUP(CURR-OBJ))C'"PGnum"")) 
I  B_REF(SUP(CURR-OBJ))(<numberstring>) 
I  B_REF(SUP(CURR-OBJ))(<string>); 

$PREFIX 
$SUFFIX 
$NUMBER 
$NUMBERSTRING 
SSTRING 
") 


DEFINE(DocLogRootGFS. 
<construction-expr>  ::= 


<construction-term> 

I  <construction-type>; 


<construction-term>     ;:=  <construction-factor> 

I  OPT  <construction-factor> 
I  REP  <construction-factor> 
I  OPT  REP  <construction-factor>; 

<construction-type>     ::=  SEQ({<construction-term>}...) 

I  CHO({<construction-term>}...); 


<construction-factor>    ::=  OBJECT_CLASS_ID_OF{Passage) 

I  OBJECT_CLASS_ID_OF(NumberedSegment) 
I  <construction-type>; 

") 


DEFINE(C0NSTRAINT-1.  " 
<constraint-1>  ::=  <construction-term> 

I  <construction-type>; 


<construction-term>     ::=  <constaiction-factor> 

I  OPT  <construction-factor> 
I  REP  <construction-factor> 
1  OPT  REP  <construction-factor>; 


<construction-type>     ::=  SEQ({<construction-term>}...) 

I  CHO({<construction-term>}...); 

<construction-factor>    ;;=  OBJECT_CLASS_ID_OF(Passage) 

I  OBJECT_CLASS_ID_OF(NumberedSegment) 

I  OBJECT_CLASS_ID_OF(Paragraph) 

I  OBJECT_CLASS_ID_OF(BodyText) 

I  OBJECT_CLASS_ID_OF(BodyRaster) 

I  OBJECT_CLASS_ID_OF(BodyGeometric) 

I  OBJECT_CLASS_ID_OF(Figure) 

I  OBJECT_CLASS_ID_OF(Table) 

I  OBJECT_CLASS_ID_OF(NumberedList) 

I  OBJECT_CLASSJD_OF(UnNumberedList) 

I  OBJECT_CLASSJD_OF(DefinitionList) 


143 


") 


I  <construction-type>; 


DEFINE(CONSTRAINT-2.  " 

<constraint-2>  ::=  OBJECT_CLASS_ID_OF(Title) 

I  OPT  OBJECT_CLASS_ID_OF(Title); 

") 


DEFINE(PassageGFS.  " 
<cx3nstruction-expr>     ::=  <constraint-1> 

I  SEQ(<constraint-2><constraint-1>); 

$C0NSTRAINT-1 
$C0NSTRAINT-2 
") 


DEFINE(NumberedSegmentGFS. " 
<construction-expr>  ::= 

SEQ(<term- 1  >(<constraint-2>]I<constraint- 1  >]) ; 


<term-1> 


OBJECT_CLASS_ID_OF(Number) ; 


$C0NSTRAINT-1 
$C0NSTRAINT-2 
") 


DEFINE(C0NSTRAINT-3. 
<construction-expr>  ::= 


<constajction-term> 

I  <construction-type>; 


<construction-term> 


<cx)nstaiction-factor> 

I  OPT  <construction-factor> 
I  REP  <construction-factor> 
I  OPT  REP  <construction-factor>; 


<construction-type> 


SEQ({<construction-term>}...) 

I  CHO({<constnjction-term>}...); 


<construction-factor>    ::=  OBJECT_CLASS_ID_OF(BoclyText) 

I  OBJECT_CLASS_ID_OF(BodyRaster) 
I  OBJECT_CLASS_ID_OF(BodyGeometric) 
I  OBJECT_CLASS_ID_OF(Footnote) 
I  OBJECT_CLASS_ID_OF(Phrase) 
I  OBJECT_CLASS_ID_OF(Reference) 
I  <construction-type>; 


DEFINE(ParagraphGFS.  "$CONSTRAINT-3") 
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DEFINE(TitleGFS,  "$C0NSTRAINT-3") 


pEFINE(FigureGFS. " 
<constaiction-expr>  ::= 

SEQ([<term-1  >][<term-2>][<term-3>]<term-4>) 
I  SEQ([<term-1  >][<term-2>]<term-4>[<term-3>]) 
I  SEQ((<term-3>][<term-1>][<term-2>]<term-4>) 
I  SEQ(<term-4>[<term-1  >][<term-2>][<term-3>]) 
I  SEQ(I<term-3>]<term-4>[<term-1  >][<term-2>]) 
I  SEQ(<term-4>(<term-3>][<term-1  >][<term-2>]); 

<term-1>  ::=  OBJECT_CLASS_ID_OF{Number) 

I  OPT  OBJECT_CLASS_ID_OF(Number); 
<term-2>  ::=  OBJECT_CLASS_ID_OF(Caption) 

I  OPT  OBJECT_CLASS_ID_OF(Caption); 
<term-3>  ::=  OBJECT_CLASS_ID_OF(Description) 

I  OPT  OBJECT_CLASS_ID_OF(Description); 
<term-4>  ::=       OBJECT_CLASS_ID_OF(  Artwork) 

I  OBJECT_CLASSJD_OF(Form); 

") 


DEFINE(ArtworkGFS. 
<construction-expr> 


<construction-term> 


<constj'uction-type> 
<construction-factor> 


<construction-term> 

I  <construction-type>; 

<construction-factor> 

I  OPT  <construction-factor> 
I  REP  <construction-tactor> 
I  OPT  REP  <construction-factor>; 

SEQ({<construction-term>}. . .) 

I  CHO{{<construction-term>}...); 

OBJECT_CLASS_ID_OF(Phrase) 

I  OBJECT_CLASS_ID_OF(BodyRaster) 
I  OBJECT_CLASS_ID_OF(BodyGeometric) 
I  <constmction-type>; 


DEFINE(C0NSTRAINT-5. 
<constnjction-expr>  ::= 


<construction-term> 


<construction-type> 


<construction-term> 

I  <construction-type>; 

<construction-factor> 

I  OPT  <construction-factor> 
I  REP  <construction-factor> 
I  OPT  REP  <construction-factor>; 

SEQ({<construction-temi>}. . .) 

I  CHO({<construction-term>}...); 


<construction-factor> 


OBJECT_CLASS_ID_OF(Phrase) 
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I  OBJECT_CLASS_ID_OF(Footnote) 
I  OBJECT_CLASS_ID_OF(Reference) 
I  OBJECT_CLASS_ID_OF(BodyText) 
I  <construction-type>; 


DEFINE(PhraseGFS.  "$C0NSTRAINT-5") 


DEFINE(CaptionGFS.  "$C0NSTRAINT-5") 


DEFINE(DescriptionGFS.  "$C0NSTRAINT-5") 


DEFINE(FootnoteGFS.  " 
<construction-expr>  ::= 

SEQ(OBJECT_CLASS_ID_OF(FootnoteReference) 
OBJECT_CLASS_ID_OF(FootnoteBody)); 

") 


DEFINE(FootnoteBodyGFS. 
<construction-expr>  ::= 


SEQ(OBJECT_CLASSJD_OF(FootnoteNumber) 
<term-1>); 


<term-1> 


OBJECT_CLASS_ID_OF(FootnoteText) 

I  OBJECT_CLASS_ID_OF(Reference) 

I  REP  OBJECT_CLASS_ID_OF(FootnoteText) 

I  REP  OBJECT_CLASS_ID_OF(Reference) 

I  CHO({OBJECT_CLASS_ID_OF(FootnoteText) 

I  OBJECT_CLASS_ID_OF(Reference)}..  ) 
I  REP  CHO({OBJECT_CLASS_ID_OF(FootnoteText) 

I  OBJECT_CLASSJD_OF(Reference)) . . .) ; 


DEFINE(ReferenceGFS. 
<construction-expr> 


<term>  ::= 


OBJECT_CLASS_ID_OF{ReferencedContent) 
I  SEQ([<term>] 

OBJECT_CLASS_ID_OF{ReferencedContent) 

(<term>]); 
OBJECT_CLASS_ID_OF(BodyText) 
I  OPT  OBJECT_CLASS_ID_OF(BodyText) 
I  CHO(  {OBJECT_CLASS_ID_OF(BodyText)}...  ); 


DEFINE(CommonContentGFS,  " 
<coflstruction-expr>     ::=  <construction-factor> 

I  SEQ(<construction-factor>...); 

<construction-factor>    ::=  OBJECT_CLASS_ID_OF(CommonText) 

I  OBJECT_CLASS_ID_OF(PageNumber) 
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I  OBJECT_CLASS_ID_OF(CommonRaster) 
I  OBJECT_CLASS_ID_OF(CommonGeometric) 
I  OBJECT_CLASS_ID_OF(CommonReference) 
I  OBJECT_CLASS_ID_OF(CommonNumber) 
I  OBJECT_CLASS_ID_OF(Currentlnstance) 
I  OBJECT_CLASS_ID_OF(TableNumber); 

") 


DEFINE(TableGFS." 

<construction-expr>  ::=  REP  CHO(OBJECT_CLASSJD_OF(Row)...) 

I  REP  OBJECT_CLASS_ID_OF(Row) 
I  SEQ(OBJECT_CLASS_ID_OF(Row)...); 


DEFINE(RowGFS," 
<construction-expr>  ::= 
<simple-table> 


<cxDmplex-table> 


DEFiNE(TableComponentGFS," 

<construction-expr>  ::=  REP  OBJECT_CLASS_ID_OF(RowComponent); 


DEFINE(RowComponentGFS," 

<construction-expr>  ::=  REP  OBJECT_CLASS_ID_OF(EntryElement) 

|REP  CHO(OBJECT_CLASS_ID_OF(EntryElement)...) 
|SEQ{OBJECT_CLASSJD_OF(EntryElement)...); 

") 


DEFINE(FormGFS," 
«x>nstruction-expr>  ::=  AGG(<factor>...); 
<factor>  :;=  OBJECT_CLASS_ID_OF(EntryEiement) 

|OBJECT_CLASSJD_OF(EntryGroup); 

••) 


DEFINE(EntryGroupGFS,"$FormGFS") 


DEFINE(EntryElementGFS," 

<construction-expr>  ::=  OBJECT_CLASS_ID_OF(EntryText) 

|OBJECT_CLASSJD_OF(EntryRaster) 
|OBJECT_CLASSJD_OF(EntryGeometric); 


<simple-table>  |  <complex-table>; 
REP  OBJECT_CLASS_ID_OF(EntryElement) 
I  REP  CHO(OBJECT_CLASS_ID_OF(EntryElement)...) 
I  SEQ(OBJECT_CLASS_ID_OF(EntryElement)...); 
SEQ(OBJECT_CLASS_ID_OF(EntryElement) 
OBJECT_CLASS_ID_OF{TableComponent)); 
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DEFINE(NumberedListGFS. 
<construction-expr>  ::= 


") 


SEQ(OBJECT_CLASS_ID_OF{Number) 

OBJECT_CLASS_ID_OF(Listltem)) 
I  REP  SEQ(OBJECT_CLASS_ID_OF(Number) 
OBJECT_CLASS_ID_OF(Listltem)); 


DEFINE(UnNumberedListGFS; 
<construction-expr>  ::= 


OBJECT_CLASS_ID_OF(Listltem) 

I  REP  OBJECT_CLASS_ID_OF(Listltem) 

I  SEQ(<separator-obj>  OBJECT_CLASS_ID_OF(Listltem)) 

I  REP  SEQ(<separator-obj>  OBJECT_CLASS_ID_OF(Listltem)); 


<separator-obj> 


") 


::=  OBJECT_CLASS_ID_OF(BodyText) 

|OBJECT_CLASSJD_OF(BodyRaster) 
|OBJECT_CLASS_ID_OF(BodyGeometric); 


DEF!NE(DefinttionUstGFS." 

<construction-expr>    ;:=  SEQ(OBJECT_CLASSJD_OF(ListTerm) 
OBJECT_CLASS_ID_OF(Listltem)) 
|REP  SEQ(OBJECT_CLASS_ID_OF(ListTerm) 
OBJECT_CLASS_ID_OF(Listltem)); 

") 


DEFINE(ListltemGFS, 
<cx>nstruction-expr> 

<term> 


::=  <term>  |  CHO(<term>...)  ; 

::=  REP  OBJECT_CLASS_ID_OF(Phrase) 
I  OBJECT_CLASS_ID_OF(NumberedList) 
I  OBJECT_CLASS_ID_OF(UnNumberedList) 
I  OBJECT_CLASS_ID_OF(DefinitionList); 


DEFINE(ListTermGFS,"$C0NSTRAINT-3") 


7.3.2  Factor  constraints 


7.3.2.1  FACTOR  ANY-LOGICAL 


GENERIC 
REQ 
REQ 

SPECIFIC 
PERM 
REQ 
REQ 

SPECIFIC 


Object -type 
Object-class-identifier 

Object-type 
Object-identifier 
Object-class 

AND  GENERIC; 


{VIRTUAL}, 
{ANY_VALUE} 

{VIRTUAL}. 

{ANY_VALUE}. 

{VIRTUAL} 
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PERM  Protection  {ANY_VALUE}. 

PERM  User-readable-comments  {ANY_STRING}, 

PERM  User-visible-name  {ANY_STRING} 

] 


7.3.2.2  FACTOR  COMP-LOGICAL 


:ANY-LOGICAL  { 
GENERIC: 

REQ  Object-type 
SPECIFIC: 

REQ  Subordinates 

PERM  Object-type 
SPECIFIC_AND_GENERIC: 

PERM  Bindings 

PERM  Default-value-lists 


{'composite-logical-object'} 
{VIRTUAL}, 

{'composite-logical-object'} 

{PMUL  {SSPECIFYBINDINGS}}, 
{REQ  #basic-logical-attributes 

{PERM  #presentation-style  {ANY_VALUE}. 

PERM  #layout-style  {ANY_VALUE}}} 


7.3.2.3  FACTOR  BASIC-LOGICAL 

:ANY-LOGICAL  { 
GENERIC: 

REQ  Object-type 

PERM  Resource 
SPECIFIC: 

PERM  Object-type 
SPECIFIC_AND_GENERIC: 

PERM  Bindings 


{'basic-logical-object'}, 
{ANY_VALUE} 

{'basic-logical-object'} 

{PMUL  {SSPECIFYBINDINGS}} 


7.3.2.4  FACTOR  ANY-COMMON 


GENERIC 
REQ 
REQ 
PERM 
PERM 
PERM 
PERM 

} 


Object-type 
Object-class-identifier 

Bindings 

Protection 

User-readable-comments 
User-visible-name 


{VIRTUAL}, 
{ANY_VALUE}, 

{PMUL  {SSPECIFYBINDINGS}}. 
{ANY_VALUE}, 
{ANY_STRING}, 
{ANY_STRING} 
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7.3.3  Constituent  constraints 


7.3.3.1  DocumentLogicalRoot 

:ANY-LOGICAL  { 

GENERIC: 

REQ  Object-type 

REQ  Generator-for-subordinates 

REQ  Application-comments 

SPECIFIC: 

PERM  Object-type 
REQ  Object-class 
REQ  Subordinates 

PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Bindings 

PERM  Default-value-lists 


} 


7,3.3.2  Passage 

:COMP-LOGICAL  { 

GENERIC: 

REQ  Generator-for-subordinates 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
REQ  Subordinates 


PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Bindings 


{'document-logical-root'}, 

{$DocLogRootGFS}, 

{REQ  #constraint-name  {"0"}, 

PERM  #external-data  {ANY_VALUE}} 

{'document-logical-root'}, 

{OBJECT_CLASSJD_OF(DocumentLogicalRoot)}, 
{SUB_ID_OF(NumberedSegment)+. 

SUB_ID_OF(Passage}+}, 
{REQ  #constraint-name  {"0"}. 

PERM  #external-data  {ANY_ VALUE}} 

{PMUL  {$SPECIFYBINDINGS}, 
PERM  {$INITIALISEFNOTE}}. 
{REQ  #basic-logical-attributes 

{PERM  #presentation-style  {ANY_VALUE}, 
PERM  #layout-style  {ANY_VALUE}}} 


{$PassageGFS}, 
{REQ  #constraint-name  ("1"}, 
PERM  #extemal-data  {ANY_ VALUE}} 

{OBJECT_CLASS_ID_OF(Passage)}, 
{SUB_ID_OF(Title). 
SUB_ID_OF(Passage)-t-, 
SUB_ID_OF(NumberedSegment)+. 
SUB_ID_OF(BodyText)-t-. 
SUB_ID_OF(BodyRaster)-h, 
SUB_ID_OF(BodyGeometric)-i-, 
SUB_ID_OF(Figure)-^, 
SUBJD_OF(Paragraph)-t-, 
SUBJD_OF(Table)+, 
SUB_ID_OF(NumberedList)-f-. 
SUB_ID_OF(DefinitionList)-(-. 
SUBJD_OF(UnNumberedList)+}, 
{REQ  #constraint-name  {"1"}, 
PERM  #external-data  {ANY_VALUE}} 

{PMUL  {$SPECIFYBINDINGS}. 
PERM  {$INITIALISEFNOTE}}, 
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PERM  Layout-Style 


{STYLEJD_0F(LStyle1)} 


7.3.3.3  NumberedSegment 

:COMP-LOGICAL  { 

GENERIC; 

REQ  Generator-for-subordinates 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
REQ  Subordinates 


PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Layout-style 

} 


{$NumberedSegmentGFS}, 
{REQ  #constraint-name  {"2"}, 
PERM  #extemal-data  (ANY_VALUE}} 

{OBJECT_CLASS_ID_OF(NumberedSegment)}, 
{SUB_ID_OF(Number), 
SUBJD_OF(Title), 
SUB_ID_OF(Passage)+, 
SUB_ID_OF(NumberedSegment)-H. 
SUB_ID_OF(BodyText)+. 
SUBJD_OF(BodyRaster)+, 
SUB_ID_OF(BodyGeometric)+, 
SUB_ID_OF(Paragraph)-i-, 
SUBJD_OF(Figure)+, 
SUB_ID_OF(Table)-K, 
SUB_ID_OF(NumberedList)-H. 
SUB_ID_OF(DefinitionList}-h, 
SUB_ID_OF(UnNumberedList)-K}. 
{REQ  #constraint-name  {"2"}. 
PERM  #extemal-data  {ANY_VALUE}} 

{STYLEJD_0F(LStyle1)} 


7.3.3.4  Number 

:BASIC-LOGICAL  { 

GENERIC: 

REQ  Content-generator 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
PERM  Content-generator 
PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Layout-Style 
PERM  Presentation-style 
PERM  Content-architecture-class 

} 


{$SEGMENTNUMBER}, 
{REQ  #constraint-name  {"3"}. 
PERM  #external-data  {ANY_VALUE}} 

{OBJECT_CLASSJD_OF{Number)}. 
{SSEGMENTNUMBER}, 
{REQ  #constraint-name  {"3"}, 
PERM  #external-data  {ANY_VALUE}} 

{STYLEJD_0F(LStyle2)}. 
{STYLE_ID_OF(PStyle1 )}, 
{$FC|$PC|$FPC} 
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7.3.3.5  Titae 


:COMP-LOGlCAL  { 
GENERSC: 

REQ 

REQ 


Generator-for-subordinates 
-comments 


SPECIFIC 
REQ 
REQ 


Object-class 
Subordinates 


PERM  Application-comments 


_AND_GENER1C: 
Layout-style 


PEW 


{$T!tleGFS}, 

{REQ  #constraint-name  {"4"}. 
PERM  #extemal-data  {ANY_VALUE}) 

{OBJECT_CLASS_ID_OF(Title)}. 
{SUBJD_OF(BodyText)-^, 

SUBJD_OF(BodyRaster)-^. 

SUBJD_OF(BodyGeometric)+. 

SUBJD_OF(Phrase)+. 

SUB_ID_OF(Footnote)+. 

SUBJD_OF(Reference)+}. 
{REQ  #constraint-name  {"4"}, 

PERM  #extemal-data  {ANY_VALUE}} 

{STYLEJD_0F(LStyle1)} 


7.3.3.6  Captioo 

:COMP-LOGICAL  { 
GENERIC; 

REQ  Generator-for-subordinates 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
REQ  Subordinates 


PERM 

SPECIFIC. 
PERM 


} 


_GENERIC: 
Layout-style 


{SCaptionGFS}. 
{REQ  #constraint-name  {"5"}, 
PERM  #external-data  {ANY_VALUE}} 

{OBJECT_CLASS_ID_OF(Caption)}. 
{SUB_ID_OF(BodyText)-H, 

SUBJD_OF(Phrase)+, 

SUB_ID_OF(Footnote)-H, 

SUBJD_OF(Reference)+}. 
{REQ  #constraint-name  {"5"}, 

PERM  #extemal-data  {ANY_VALUE}} 

{STYLE_ID_0F{LStyle1)} 


7.3.3.7  Paragraph 

:COMP-LOGICAL  {        -     ■  ' 
GENERIC: 

REQ  Generator-for-subordinates 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
REQ  Subordinates 


{$ParagraphGFS}. 
{REQ  #constraint-name  ("6"}. 
PERM  #extemal-data  {ANY_VALUE}} 

{OBJECT_CLASS_ID_OF(Paragraph)}, 
{SUBJD_OF(BodyText)-(-. 
SUBJD_OF{Footnote)+. 
SUB_ID_OF(BodyRaster)+. 
SUBJD_OF(BodyGeometric)-H, 
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PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Layout-style 

} 


SUB_ID_OF(Phrase)+. 
SUBJD_OF(Reference)+}. 
{REQ  #constraint-name  {"6"}, 
PERM  #extemal-data  {ANY_VALUE}} 

{STYLE_ID_0F(LStyle1)} 


7.3.3.8  Phrase 

:COMP-LOGICAL  { 

GENERIC: 

REQ  Generator-for-subordinates 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
REQ  Subordinates 


PERM  Application-comments 

SPECIFIC,  AND_GENERIC: 
PERM  Layout-style 

} 


{$PhraseGFS}. 
{REQ  #constraint-name  {"7"}, 
PERM  #extemal-data  {ANY_VALUE}} 

{OBJECT_CLASSJD_OF(Phrase)}. 
{SUBJD_OF(BodyText)+. 
SUBJD_OF(Footnote)+, 
SUBJD_OF(Phrase)-t-. 
SUB_ID_OF(Reference)+}, 
{REQ  #constraint-name  {"7"}, 
PERM  #extemal-data  {ANY_VALUE}} 

{STYLE_ID_0F(LStyle1)} 


7.3.3.9  Footnote 

:COMP-LOGICAL  { 
GENERIC: 

REQ  Generator-for-subordinates 

PERM  Bindings 


REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
REQ  Subordinates 

PERM  Bindings 

PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Layout-style 

} 


{$FootnoteGFS}, 

{PMUL  {$SPECIFYBINDINGS}, 

PERM{REQ{$INCFNOTENUMBER,$FNOTENUMBERSTRING} 

I  $FNOTESTRINGLITERAL}  }, 
{REQ  #constraint-name  {"8"}, 
PERM  #extemal-data  {ANY_VALUE}} 

{OBJECT_CLASS_ID_OF(Footnote)}, 
{SUB_ID_OF(FootnoteReference). 

SUB_ID_OF(FootnoteBody)}. 
{PMUL  {SSPECIFYBINDINGS}, 

PERM  {$FNOTESTRINGLITERAL}}, 
{REQ  #constraint-name  {"8"}, 

PERM  #extemal-data  {ANY_VALUE}} 

{STYLE_ID_0F(LStyle1)} 
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7.3.3.10  FootnoteNumber 


:BASIC-LOGICAL  { 

GENERIC; 

REQ  Content-generator 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
PERM  Content-generator 
PERM  Application-comments 

SPEC1FIC_AND_GENERIC : 
PERM  Layout-style 
PERM  Presentation-style 
PERM  Content-architecture-class 


{SFNNUMBER}, 
{REQ  #constraint-name  {"9"}. 
PERM  #extemal-data  {ANY_VALUE}} 

{OBJECT_CLASS_ID_OF(FootnoteNumber)}. 
{SFNNUMBER}, 
{REQ  #constraint-name  {"9"}, 
PERM  #extemal-data  {ANY_ VALUE}} 

{STYLEJD_0F(LStyle9)), 
{STYLEJD_0F(PStyle1)}, 
{$FC|$PC|$FPC} 


7.3.3.1 1  FootnoteReference 


:BASIC-LOGICAL  { 
GENERIC; 

REQ  Content-generator 
REQ  Application-comments 

SPECIFIC; 

REQ  Object-class 
PERM  Content-generator 
PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Layout-style 
PERM  Presentation-style 
PERM  Content-architecture-class 


{SFNNUMBER}, 
{REQ  #constraint-name  {"10"}, 
PERM  #external-data  {ANY_VALUE}} 

{OBJECT_CLASS_ID_OF(FootnoteReference)}. 
{SFNNUMBER}, 
{REQ  #constraint-name  ("10"}. 
PERM  #external-data  {ANY_VALUE}} 

{STYLE_ID_0F(LStyle1 0)}, 

{STYLEJD_OF{PStylel)}. 

{SFC|SPC|$FPC} 


7.3.3.12  FootnoteBody  v 

;COMP-LOGICAL  { 

GENERIC; 

REQ  Generator-for-subordinates 
REQ  Application-comments 

SPECIFIC; 

REQ  Object-class 
REQ  Subordinates 


PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Layout-style 

} 


{SFootnoteBodyGFS}, 
{REQ  #constraint-name  {"11"}. 
PERM  #external-data  {ANY_VALUE}} 

{OBJECT_CLASS_lD_OF(FootnoteBody)}, 
{SUBJD__OF(FootnoteNumber), 

SUB_ID_OF(FootnoteText)-t-, 

SUB_ID_OF(Reterence)+}, 
{REQ  #constraint-name  {"11"}, 

PERM  #extemal-data  {ANY_VALUE}} 

{STYLEJDlOF(LStylell)} 
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7.3.3.13  FootnoteText 


:BASI,C-LOGICAL  { 
GENERIC: 

REQ  Application-comments 

SPECIFIC; 

REQ  Object-class 

PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Layout-style 
PERM  Presentation-style 
PERM  Content-architecture-class 


{REQ  #constraint-name  ("12"}, 
PERM  #external-data  {ANY_VALUE}} 

{OBJECT_CLASS_ID_OF(FootnoteText)}, 
{REQ  #constraint-name  {"12"}, 
PERM  #external-data  {ANY_VALUE}} 

{STYLE_ID_0F(LStyle6)}, 
{STYLE_ID_0F(PStyle1)}, 
{$FC|$PC|$FPC}, 


PERM  Content-portions 


{CONTENTJD_OF(Character-content-ponion)-t-} 


7.3.3.14  Figure 

:COMP-LOGICAL  { 

GENERIC; 

REQ  Generator-for-subordinates 
REQ  Application-comments 

SPECIFIC; 

REQ  Object-class 
REQ  Subordinates 


PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Layout-style 

} 


{$FigureGFS}. 

{REQ  #constraint-name  {"13"}, 
PERM  #external-data  {ANY_VALUE}} 

{OBJECT_CLASS_ID_OF(Figure)}. 
{SUB_ID_OF{Number), 

SUB_ID_OF(Caption), 

SUBJD_OF(Description), 

SUB_ID_OF(Artwork), 

SUB_ID_OF(Form)}, 
{REQ  #constraint-name  {"13"}, 

PERM  #external-data  {ANY_VALUE}} 

{STYLEJD_0F(LStyle1)} 


7.3.3.15  BodyText 

;BASIC-LOGICAL  { 
GENERIC; 

REQ  Application-comments 

SPECIFIC; 

REQ  Object-class 

PERM  Application-comments 

SPECIFIC_AND_GENERIC; 
PERM  Layout-style 
PERM  Presentation-style 
PERM  Content-architecture-class 


{REQ  #constraint-name  {"14"}, 
PERM  #external-data  {ANY_VALUE}} 

{OBJECT_CLASS_ID_OF(BodyText)}. 
{REQ  #constraint-name  {"14"}, 
PERM  #external-data  {ANY_VALUE}} 

{STYLE_ID_0F(LStyle2)}. 
{STYLEJD_0F(PStyle1)}, 
{$FC|$PC|$FPC}, 
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PERM   Content-portions  {CONTENT_ID_OF(Character-content-portion)+} 

--  The  attribute  "content  portions"  must  be  specified  either  in  the  specific  or  generic  part, 
otherwise  the  attribute  "resource"  must  be  specified.  -- 

1 

7.3.3.16  Reference 

:COlVlP-LOGICAL  { 
GENERIC: 

REQ  Generator-for-subordinates 

REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
REQ  Subordinates 

PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Layout-Style 

} 


{$ReferenceGFS}, 
{REQ  #constraint-name  {"15"}. 
PERM  #extemal-data  {ANY_VALUE}} 

{OBJECT_CLASS_ID_OF(Reference)}. 
{SUB_ID_OF(BodyText)+. 

SUB_ID_OF(ReferencedContent)}. 
{REQ  #constraint-name  {"15"}. 

PERM  #extemal-data  {ANY_VALUE}} 

{STYLEJD_0F(LStyle1)} 


7.3.3.17  ReferencedContent 


:BASIC-LOGICAL  { 
GENERIC: 

REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
PERM  Content-generator 
PERM  Content-portions 

PERM  Application-comments 

SPECIFIC_AND_GENERIC: 

PERM  Layout-style 
PERM  Presentation-style 
PERM  Content-architecture-class 


{REQ  #constraint-name  {"16"}, 
PERM  #extemal-data  {ANY_VALUE}} 

{OBJECT_CLASS_ID_OF(ReferencedContent)}. 
{$REF}. 

{CONTENT_ID_OF(Character-content-portion)-h}, 
-  Either  Content-generator  or  Content-portions  is  specified 

{REQ  #constraint-name  {"16"}, 
PERM  #extemal-data  {ANY_ VALUE}} 


{STYLEJD_OF(LStyle10)}. 
{STYLEJD_0F(PStyle1 )}, 
{$FCI$PC|$FPC} 


7.3.3.18  BodyRaster 

:BASIC-LOGICAL  { 

GENERIC: 

REQ  Content-architecture-class 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 

PERM  Content-architecture-class 

PERM  Application-comments 


{$FPR}. 

{REQ  #constraint-name  {"17"}, 
PERM  #extemal-data  {ANY_VALUE}} 

{OBJECT_CLASS_ID_OF(BodyRaster)}. 
{$FPR}, 

{REQ  #constraint-name  {"17"}. 
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PERM  #external-data  {ANY_VALUE}} 

SPECIFIC,  AND_GENERIC: 

PERM  Layout-style  {STYLE_ID_0F(LStyle5)}, 
PERM    Presentation-style  {STYLE_ID_0F(PStyle3)), 

PERM   Content-portions  {CONTENTJD_OF(Raster-graphics-content-portion)} 
-  The  attribute  "content  portions"  must  be  specified  either  in  the  specific  or  generic  part, 
otherwise  the  attribute  "resource"  must  be  specified.  - 


7.3.3.19  BodyGeometric 


;BASIC-LOGICAL  { 


GENERIC 

REQ 

Content-architecture-class 

{$FPG}, 

REQ 

Application-comments 

{REQ  #constraint-name  {"18"}, 

PERM  #external-data  {ANY_ VALUE}} 

SPECIFIC 

REQ 

Object -class 

{OBJECT  CLASS  ID_OF(BodyGeometric)}. 

PERM 

Content-architecture-class 

{$FPG}, 

PERM 

Application-comments 

{REQ  #constraint-name  {"18"}, 

PERM  #external-data  {ANY_VALUE}} 

SPECIFIC 

_AND_GENERIC: 

PERM 

Layout-style 

{STYLE  !D  0F(LStyle5)}, 

PERM 

Presentation-style 

{STYLE_ID_0F(PStyle2)}, 

PERM 

Content-portions 

{CONTENTJD_OF(Geometric-graphics-content-portion)} 

-  The  attribute  "content  portions"  must  be  specified  either  in  the  specific  or  generic  part, 
othenwise  the  attribute  "resource"  must  be  specified.  - 

} 


7.3.3.20  CommonContent 

:ANY-COMMON  { 

GENERIC: 

REQ  Object-type 

REQ  Generator-for-subordinates 

REQ  Application-comments 

PERM  Default-value-lists 


} 


7.3.3.21  CommonText 

:ANY-COMMON  { 

GENERIC: 

REQ  Object-type 
PERM  Content-portions 
PERM  Resource 
PERM  Layout-style 
PERM  Presentation-style 
PERM  Content-architecture-class 
REQ  Application-comments 


{'composite-logical-object'}, 
{SCommonContentGFS}. 
{REQ  #constraint-name  {"19"}. 
PERM  #external-data  {ANY_ VALUE}}, 
{REQ  #basic-logical-attributes 

{PERM  #presentation-style  {ANY_VALUE}, 
PERM  #layout-style  {ANY_VALUE}}} 


{'basic-logical-object'}, 

{CONTENT_ID_OF{Character-content-portion)+}, 
{ANY_VALUE}, 
{STYLEJD_0F(LStyle3)}. 
{STYLE_ID_0F(PStyle4)}, 
{$FC|$PC|$FPC}, 
{REQ  #constraint-name  {"20"}, 
PERM  #external-data  {ANY_VALUE}} 
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} 


--  Either  the  attribute  "content  porlions"  or  "resource"  must  be  specified  in  the  above  constituent 
constraint.  -- 


7.3.3.22  CommonReference 

;ANY-COMMON  { 

GENERIC: 

REQ  Object-type 
PERM  Content-generator 
PERM  Layout-style 
PERM  Presentation-style 
PERM  Content-architecture-class 
REQ  Application-comments 


{ basic-logical-object  ■} , 
{$COMMONREF}. 
{STYLEJD_0F(LStyle3)}. 
{STYLE_ID_0F(PStyle4)}. 
{$FC|$PC|$FPC}, 
{REQ  #constraint-name  {"37"}, 
PERM  #extemal-data  {ANY_ VALUE}) 


7.3.3.23  CommonNumber 

:ANY-COMMON  { 

GENERIC 

REQ    Object -type 
PERM  Content-generator 
PERM  Layout-style 
PERM  Presentation-style 
PERM  Content-architecture-class 
REQ  Application-comments 


{'basic-logical-object}, 
{SCOMMONNUMBER}, 
{STYLE_ID_0F(LStyle3)}. 
{STYLE  JD_0F(PStyle4)}, 
{$FC|$PC|$FPC}. 
{REQ  #constraint-name  ("38"}, 
PERM  #external-data  {ANY_ VALUE}} 


7.3.3.24  Currentlnstance 

:ANY-COMMON  { 

GENERIC: 

REQ    Object -type 
PERM  Content-generator 
PERM  Layout-style 
PERM  Presentation-style 
PERM  Content-architecture-class 
REQ  Application-comments 


{ 'basic- togical-object'}, 
{SCURRENTINSTANCE}, 
{STYLEJD_0F(LStyle3)}, 
{STYLE_ID_0F{PStyle4)), 
{$FC|$PC|$FPC}, 
{REQ  #constraint-name  {"39"}. 
PERM  #external-data  {ANY_VALUE}} 


7.3.3.25  CommonRaster 


:ANY-COMMON  { 
GENERIC: 

REQ    Object-type  {'basic-logical-object'}, 

PERM    Content-portions  {CONTENTJD_OF(Raster-graphics-content-portion)}, 

PERM    Resource  {ANY_VALUE}, 

PERM    Layout-style  {STYLEJD_0F(LStyle8)}, 
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PERM   Presentation-style  {STYLEJD_0F(PStyle3)}, 

REQ    Content-architecture-class  {$FPR}, 

REQ    Application-comments         {REQ  #constraint-name  {"21"}. 

PERM  #external-data  {ANY_VALUE}} 

-  Either  the  attribute  "content  portions"  or  "resource"  must  be  specified  in  the  above  constituent 

constraint.  - 


7.3.3.26  CommonGeometric 


:ANY-COMMON 
GENERIC: 


REQ  Object-type 

PERM  Content-portions 

PERM  Resource 

PERM  Layout-style 

PERM  Presentation-style 

REQ  Content-architecture-class 

REQ  Application-comments 


{'basic-logical-object'}, 

{CONTENTJD_OF(Geometric-graphics-content-portion)}, 
{ANY_VALUE}. 
{STYLE_I  D_0F(LStyle8)} , 
{STYLEJD_0F(PStyle2)}, 
{$FPG}, 

{REQ  #constraint-name  {"22"}, 
PERM  #external-data  {ANY_ VALUE}} 
-  Either  the  attribute  "content  portions"  or  "resource"  must  be  specified  in  the  alcove  constituent 
constraint.  - 


7.3.3.27  PageNumber 

;ANY-COMMON  { 

GENERIC: 

REQ  Object-type 
PERM  Content-generator 
PERM  Layout-style 
PERM  Presentation-style 
PERM  Content-architecture-class 
REQ  Application-comments 


{'basic-logical-object'}, 
{$PGNUMBER}, 
{STYLE_ID_0F(LStyle3)}, 
{STYLEJD_0F(PStyle4)}, 
{$FCj$PC|$FPC}, 
{REQ  #constraint-name  {"40"}, 
PERM  #external-data  {ANY_VALUE}} 


7.3.3.28  TableNumber 

:ANY-COMMON  { 

GENERIC: 

REQ  Object-type 
PERM  Content-generator 
PERM  Layout-style 
PERM  Presentation-style 
PERM  Content-architecture-class 
REQ  Application-comments 


{'basic-logical-object'}, 
{$TABLENUMBER}, 
{STYLEJD_QF(LStyle3)}. 
{STYLEJD_0F(PStyle4)}, 
{$FC|$PC|$FPC}, 
{REQ  #constraint-name  {"44"}. 
PERM  #extemal-data  {ANY_VALUE}} 
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7.3.3.29  Description 


{$DescriptionGFS}. 
{REQ  #constraint-name  {"23"}, 
PERM  #extemal-data  {ANY_VALUE}} 


:COMP-LOGICAL  { 

GENERIC: 

REQ  Generator-for-subordinates 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
REQ  Subordinates 


PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Layout-style 

} 


7.3.3.30  Artwork 

:COMP-LOGICAL  { 

GENERIC: 

REQ  Generator-for-subordinates 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
REQ  Subordinates 


PERM  Application-comments 

SPECIFIC,  AND_GENERIC: 
PERM  Layout-style 

) 


7.3.3.31  NumberedList 

:COMP-LOGICAL  { 

GENERIC: 

REQ  Generator-for-subordinates 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
REQ  Subordinates 

PERM  Application-comments 

SPECIFIC_AND_GENERIC : 
PERM  Layout-Style 

} 


{OBJECT_CLASS_ID_OF(Description)}. 
{SUB_ID_OF(BodyText)-^. 
SUB_ID_OF(Footnote)+, 
SUBJD_OF(Phrase)-»-. 
SUB_ID_OF(Reference)-^}. 
{REQ  #constraint-name  {"23"), 
PERM  #extemal-data  {ANY_VALUE}} 


{$NumberedListGFS}. 
{REQ  #constraint-name  {"25"}, 
PERM  #extemal-data  {ANY_VALUE}} 

{OBJECT_CLASS_ID_OF(NumberedList)}. 
{SUBJD_OF(Number)+, 

SUBJD_OF(Listltem)+  }, 
{REQ  #constraint-name  {"25"}. 

PERM  #extemal-data  {ANY_VALUE}} 

{STYLE_ID_0F(LStyle1)) 


{STYLEJD_0F(LStyle1)} 


{$ArtworkGFS}. 
{REQ  #constraint-name  {"24"}, 
PERM  #extemal-data  {ANY_VALUE}} 

{OBJECT_CLASS_ID_OF(Artwork)}. 
{SUBJD_OF(BodyRaster)+, 

SUB_ID_OF(BodyGeometric)+. 

SUB_ID_OF(Phrase)+}, 
{REQ  #constraint-name  {"24"}, 

PERM  #extemal-data  {ANY_VALUE}} 

{STYLEJD_0F(LStyle1 2)} 
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7.3.3.32  UnNumberedList 

:COMP-LOGICAL  { 

GENERIC: 

REQ  Generator-for-subordinates 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
REQ  Subordinates 


PERM  Application-comments 

SPECIFIC.  AND_GENERIC: 
PERM  Layout-style 


{$UnNumberedListGFS}, 
{REQ  #constraint-name  {"26"}, 
PERM  #extemal-data  {ANY_VALUE}} 

{OBJECT_CLASSJD_OF{UnNumberedList)}. 
{SUB_ID_OF(BodyText)+. 
SUBJD_OF(BodyRaster)-h. 
SUBJD_OF(BodyGeometric)+, 
SUBJD_OF(Listltem)-h  }. 
{REQ  #constraint-name  {"26"}. 
PERM  #extemal-data  {ANY_VALUE}} 

{STYLEJD_0F(LStyle1)} 


7.3.3.33  DefinitionList 

:COMP-LOGICAL  { 

GENERIC: 

REQ  Generator-for-subordinates 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
REQ  Subordinates 

PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Layout-style 


{SDefinitionListGFS}. 
{REQ  #constraint-name  {"27"}, 
PERM  #external-data  {ANY_VALUE}} 

{OBJECT_CLASS_ID_OF(DefinitionList)}. 
{SUBJD_OF(ListTermK. 

SUBJD_OF(Listltem)+  }. 
{REQ  #constraint-name  {"27"}, 

PERM  #external-data  {ANY_VALUE}} 

{STYLE_ID_0F(LStyle1)} 


7.3.3.34  Listltem 

:COMP-LOGICAL  { 

GENERIC: 

REQ  Generator-for-subordinates 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
REQ  Subordinates 


PERM  Application-comments 
SPECIFIC_AND  GENERIC: 


{$ListltemGFS}. 
{REQ  #constraint-name  {"28"}, 
PERM  #external-data  {ANY_VALUE}} 

{OBJECT_CLASSJD_OF{Listltem)}. 

{SUBJD_OF(Phrase)-i-, 
SUBJD_OF(NumberedList)-H, 
SUB_ID_OF(UnNumberedList)-h, 
SUBJD_OF(DefinitionList)-^ }, 

{REQ  #constraint-name  {"28"}, 
PERM  #external-data  {ANY_VALUE}} 


161 


PERM  Layout-style 

} 


{STYLE_lD_0F(LStyle1)} 


7.3.3.35  ListTerm 


:COMP-LOGICAL  { 

GENERIC: 

REQ  Generator-for-subordlnates 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
REQ  Subordinates 


PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Layout-style 

} 


{$ListTermGFS}, 
{REQ  #constraint-name  {"29"}, 
PERM  #extemal-data  {ANY_VALUE}} 

{OBJECT_CLASSJD_OF(ListTerm)}, 
{SUB_ID_OF(BodyText)-H, 

SUB_ID_OF(BodyRaster)-(-, 

SUB_ID_OF(BodyGeometric)-i-, 

SUB_ID_OF(Reference)+. 

SUB_ID__OF(Phrase)-t-. 

SUB_ID_OF(Footnote)-^  }, 
{REQ  #constraint-name  {"29"}, 

PERM  #extemal-data  {ANY_ VALUE}} 

{STYLEJD_0F(LStyle1)} 


7.3.3.36  Table 


:COMP-LOGICAL  { 

GENERIC:  ^  -  . 

REQ  Generator-for-subordinates 
REQ  Application-comments 

REQ  Layout-style 
SPECIFIC: 

REQ  Qbject-class 

REQ  Subordinates 

PERM  Application-comments 

PERM  Layout-style 


{$TableGFS}, 

{REQ  #constraint-name  ("30"}, 
PERM  #extemal-data  {ANY_VALUE}}, 
{STYLE_ID_0F(LStyleT4)} 

{OBJECT_CLASS_ID_OF(Table)}. 
{SU8JD_OF(Row)+}, 
{REQ  #constraint-name  {"30"). 
PERM  #extemal-data  {ANY_VALUE}}. 
{STYLEJD_0F(LStyleT8)} 


7.3.3.37  Row 


:COMP-LOGICAL  { 

GENERIC: 

REQ  Generator-for-subordinates 
REQ  Application-comments 

REQ  Layout-style 
SPECIFIC: 

REQ  Object-class 
REQ  Subordinates 


{$RowGFS}, 

{REQ  #constraint-name  {"31"}, 
PERM  #external-data  {ANY_VALUE}}. 
{SPi'LE_ID_0F(LStyleT5)} 

{OBJECT_CLASS_ID_OF(Row)}, 
{SUBJD_OF(EntryElement)+, 
SUB_ID_OF(TableComponent)}. 
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} 


PERM  Application-comments 


{REQ  #constraint-name  {"31"}, 
PERM  #extemal-data  {ANY_VALUE}} 


{$TableComponentGFS}, 
{REQ  #constraint-name  {"32"), 
PERM  #extemai-clata  {ANY_VALUE}}. 
{STYLE_ID_0F(LStyleT6)} 


7.3.3.38  TableComponent 

:COMP-LOGICAL  { 

GENERIC; 

REQ  Generator-for-subordinates 
REQ  Application-comments 

REQ  Layout-style 
SPECIFIC: 

REQ  Object-class 

REQ  Subordinates 

PERM  Application-comments 


{OBJECT_CLASSJD_OF(TableComponent)}, 
{SUBJD_OF(RowComponent)-H}, 
{REQ  #constraint-name  {"32"}, 
PERM  #extemal-data  {ANY_VALUE}} 


7.3.3.39  RowComponent 

:COMP-LOGICAL  { 

GENERIC: 

REQ  Generator-for-subordinates 
REQ  Application-comments 

REQ  Layout-style 
SPECIFIC: 

REQ  Object-class 

REQ  Subordinates 

PERM  Application-comments 


{SRowComponentGFS}, 
{REQ  #constraint-name  {"33"}, 
PERM  #external-data  {ANY_VALUE}}, 
{STYLE_ID_0F(LStyleT7)} 

{OBJECT_CLASS_ID_OF(RowComponent)}. 
{SUBJD_OF(EntryElement)-(-}, 
{REQ  #constraint-name  {"33"}, 
PERM  #external-data  {ANY_VALUE}} 


7.3.3.40  Form 


:COMP-LOGICAL  { 

GENERIC: 

REQ  Generator-for-subordinates 
REQ  Application-comments 

REQ  Layout-style 
SPECIFIC: 

REQ  Object-class 
REQ  Subordinates 

PERM  Application-comments 


{$FormGFS}, 

{REQ  #constraint-name  {"34"}, 
PERM  #external-data  {ANY_VALUE}}. 
{STYLE_ID_0F(LStyleT1 )} 

{OBJECT_CLASSJD_OF(Form)}, 
{SUB_ID_OF(EntryElement)+, 

SUBJD_OF(EntryGroup)-h}, 
{REQ  #constraint-name  {"34"}, 

PERM  #extemal-data  {ANY_VALUE}} 
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7.3.3.41  EntryElement 


:COMP-LOGICAL  { 

GENERIC: 

REQ  Generator-for-subordinates 
REQ  Application-comments 

REQ  Layout-style 
SPECIFIC: 

REQ  Object-class 
REQ  Subordinates 


PERM  Application-comments 


{$EntryElementGFS}. 
{REQ  #constraint-name  {"35"}, 
PERM  #extemal-data  (ANY_VALUE}}. 
{STYLE_ID_0F(LStyleT2)} 

{OBJECT_CLASSJD_OF(EntryElement)}. 
{SUBJ  D_OF(EntryText) . 
SUBJD_OF(EntryRaster). 
SUB_ID_OF(EntryGeometric)} . 
{REQ  #constraint-name  {"35"}. 
PERM  #extemal-data  {ANY_VALUE}} 


7.3.3.42  EntryGroup 

:COMP-LOGICAL  { 

GENERIC: 

REQ  Generator-for-sut)ordinates 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
REQ  Sutx>rdinates 

PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Layout-style 

} 


{$En!ryGroupGFS}, 
{REQ  #constraint-name  {"36"}, 
PERM  #extemal-data  {ANY_VALUE}} 

{OBJECT_CLASS_ID_OF(EntryGroup)}. 
{SUBJD_OF(EntryElement)+. 

SUBJD_OF(EntryGroup)+}. 
{REQ  #constraint-name  {"36"}, 

PERM  #extemal-data  {ANY_VALUE}} 

{STYLEJD_0F(LStyleT3)} 


7.3.3.43  EntryText 


:BASIC-LOGICAL  { 
GENERIC: 

REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 

PERM  Application-comments 


SPECIFIC.  AND_GENERIC: 
PERM  Layout-style 
PERM  Presentation-style 
PERM  Content-architecture-class 
PERM  Content-portions 


{REQ  #constratnt-name  {"41"}, 
PERM  #extemal-data  {ANY_VALUE}} 

{OBJECT_CLASSJD_OF(EntryText)}, 
{REQ  #constraint-name  {"41"}. 
PERM  #extemal-data  {ANY_VALUE}} 


{STYLEJD_0F(LStyleT9)}. 
{STYLE_ID_0F(PStyle1)}. 
{$FC|$PC|$FPC}, 

{CONTENT_ID_OF(Character-content-portion)+} 
"  The  attribute  "content  portions"  must  be  specified  either  in  the  specific  or  generic  part, 
otherwise  the  attribute  "resource"  must  be  specified.  - 
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7.3.3.44  EntryRaster 

:BASIC-LOGICAL  { 


ncvJ 

Content-architecture-class 

{$FPR}, 

HtU 

Application-comments 

{ntu  ffconstraint-name  (  42  }, 

rbriM  ffexternai-aata   {ANY  VALUb}) 

bPcClrlU 

ntvJ 

L^Djeci-ciass 

\<jDjco  1  _ULMoo_iu_vjr^tinirynasier^j, 

r  cnivi 

oonieni-arcniieciure-ciass 

1  cnivi 

rVppilC/dllUI  1  CUI 1 II 1  Icl  lib 

iniivj   TrC'Ullolldllll  llalllt;  \  J, 

PERM  #external-data  {ANY_VALUE}} 

SPECIFIC 

_AND_GENERIC: 

PERM 

Layout-style 

{STYLE  ID  0F(LStyleT9)}, 

PERM 

Presentation-style 

{STYLEJD_0F(PStyle3)), 

PERM 

Content-portions 

{CONTENT_ID_OF(Raster-graphics-content-ponion)} 

-  The  attribute  "content  portions"  must  be  specified  either  in  the  specific  or  generic  part, 
otherwise  the  attribute  "resource"  must  be  specified.  ~ 

} 


7.3.3.45  Entry  Geometric 


:BASIC-LOGICAL  { 


GENERIC 

REQ 

Content-architecture-class 

{$FPG}, 

REQ 

Application-comments 

{REQ  #constraint-name  {"43"}, 

PERM  #external-data  {ANY_VALUE}} 

SPECIFIC 

REQ 

Object -class 

{OBJECT  CLASS  ID  OF(EntryGeometric)}, 

PERM 

Content-architecture-class 

{$FPG}. 

PERM 

Application-comments 

{REQ  #constraint-name  {"43"}, 

PERM  #external-data  {ANY_VALUE}} 

SPECIFIC 

_AND_GENERIC: 

PERM 

Layout-style 

{STYLE  ID  0F(LStyleT9)}, 

PERM 

Presentation-style 

{STYLE_ID_0F(PStyle2)}, 

PERM 

Content-portions 

{CONTENTJD_OF(Geometric-graphics-content-portion)} 

-  The  attribute  "content  portions"  must  be  specified  either  in  the  specific  or  generic  part, 
otherwise  the  attribute  "resource"  must  be  specified.  ~ 

} 


7.4  Layout  constituent  constraints 

7.4.1  Macro  definitions 

DEFINE(DocLayRootGFS,  " 

<constructlon-expr>     ::=  <construction-term>|<construction-type>; 

<construction-term>     ::=  <construction-factor> 

I  OPT  <constnjction-factor> 
I  REP  <construction-factor> 
I  OPT  REP  <construction-factor>; 

<construction-type>     ::=  SEQ(<construction-term>...) 
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I  CHO(<construction-term>...); 

<construction-factor>    ::=  OBJECT_CLASS_ID_OF(PageSet) 

I  <construction-type>; 


DEFINE(PageSetGFS. 
<construction-expr> 

<construction-term> 


<construction-type> 


<construction-factor> 


:=  <construction-term>|<construction-type>; 

:=  <construction-factor> 
I  OPT  <construction-factor> 
I  REP  <construction-factor> 
I  OPT  REP  <construction-f actor> ; 

:=  SEQ(<constaiction-term>...) 
I  CHO(<construction-term>...); 

:=  OBJECT_CLASS_ID_OF(Page) 
I  OBJECT_CLASS_ID_OF(RectoPage) 
I  OBJECT_CLASS_ID_OF(VersoPage) 
I  <construction-type>; 


") 


DEFINE(PageGFS. 
<construction-expr> 


<headerarea> 


<boclyarea> 


<foolerarea; 


:=  SEQ([<headerarea>]<bodyarea>l<footerarea>]) 
I  SEQ(<bodyarea>(<headerarea>](<footerarea>)) 
I  SEQ([<headerarea>](<footerarea>]<bodyarea>) 
I  <bodyarea>; 

:=  OBJECT_CLASS_ID_OF(BasicHeader) 
I  OBJECT_CLASS_ID_OF(CompositeHeader); 

;=  OBJECT_CLASS_ID_OF(VariableCompositeBody) 
I  OBJECT_CLASS_ID_OF(FixedCompositeBody) 
I  OBJECT_CLASS_ID_OF(BasicBody); 

:=  OBJECT_CLASS_ID_OF(BasicFooter) 
I  OBJECT_CLASS_ID_OF(CompositeFooter): 


DEFINE(CompositeCommonGFS.  " 
<construction-expr>     ::=  <fixed-common-content-frames> 

I  <variable-common-content-frames>: 

<fixed-common-content-frames> 

::=  SEQ({OBJECT_CLASSJD_OF(SourcedContentFixed) 
I  OBJECT_CLASS_ID_OF(ArrangedContentFixed)}.  .); 

<variable-common-content-frames> 

::=  SEQ({OBJECT_CLASS_ID_OF(SourcedContentVariable) 
I  OBJECT_CLASS_ID_OF(ArrangedContentVariable)}.  .); 

") 
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DEFINE(HeaderFooterGFS.  "$CompositeCommonGFS") 


DEFINE(FixedCompositeBodyGFS,  " 
<construction-expr>     ::=  SEQ{<construction-term>...); 


<construction-term> 


<construction-factor1  > 


<construction-factor2> 


::=  <construction-factor1  > 
I  OPT  <construction-factor1  > 
I  CHO({<construction-factor1  >}...) 
I  <construction-factor2>; 

;:=  OBJECT_CLASS_ID_OF{BasicFixture) 
I  OBJECT_CLASS_ID_OF(ColumnFixed) 
j  OBJECT_CLASS_ID_OF(CompositeFixtureFixed) 
I  OBJ ECT_CLASS_I D_OF( VariableCompositeBody) ; 

;:=  OBJECT_CLASSJD_OF(CompositeCommon) 
I  OBJECT_CLASS_ID_OF(SourcedContentFixed) 
I  OBJECT_CLASS_ID_OF(ArrangedContentFixed); 


DEFINE(VariableCompositeBodyGFS.  " 

<construction-expr>     ::=  <construction-term>|<construction-type> 

I  SEQ(<construction-term>,  <construction-footnote>) 
I  SEQ(<construction-type>,  <construction-footnote>); 


<construction-term>     ::=  <construction-factor1  > 

I  OPT  <construction-factor1> 
I  REP  <construction-factor1> 
I  OPT  REP  <construction-factor1>; 


<construction-type>     ::=  SEQ({<construction-term>  |  <construction-factor2>}...) 

I  CHO({<construction-term>}...); 

<construction-factor1>  ::=  OBJECT_CLASS_ID_OF(BasicFloat) 

I  OBJECT_CLASS_ID_OF(SnakingColumns) 

I  OBJECT_CLASS_ID_OF(SynchronizedColumns) 

I  OBJECT_CLASS_ID_OF(CompositeFloat) 

I  OBJECT_CLASSJD_OF(CompositeFixtureVariable) 

I  OBJECT_CLASS_ID_OF(TableArea) 

I  OBJECT_CLASS_ID_OF(FootnoteArea) 

I  <construction-type>; 


<construction-footnote>  ;:=  OBJECT_CLASS_ID_OF(FootnoteArea) 

I  OPT  OBJECT_CLASS_ID_OF(FootnoteArea); 

<construction-factor2>  :;=  OBJ ECT_CLASS_ID_OF(ArrangedContent Variable) 

I  OBJECT_CLASS_ID_OF(SourcedContentVariable); 


DEFINE(SnakingColumnsGFS,  " 
<consiruction-expr>     ;.=  REP  <construction-factor1  > 
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I  <construction-term> 

I  SEQ(<construction-type>...); 
<construction-term>     ::=  SEQ(<construction-type><following-term>); 
<following-term>         ::=  OPT<constajction-factor1  > 

I  <construction-tactor2> 

I  OPT<construction-term>  ; 

<cx)nstruction-type>     ::=  <construction-factor1  >|<construction-factor2>; 
<construction-factor1  >  ::=  OBJECT_CLASS_ID_OF(ColumnVariable) 

I  OBJECT_CLASS_ID_OF(CompositeColumn Variable); 
<construction-factor2>  ::=  OBJ ECT_CLASSJD_OF(ArrangedContent Variable) 

I  OBJECT_CLASSJD_OF(SourcedContentVariable); 

") 


DEFiNE(SynchronizedColumnsGFS.  " 
<cx)nstruction-expr>     ::=  SEQ({<construction-type>} 


.)|<construction-term>; 


::=  SEQ(<construction-type><following-teim>); 
:;=  OPT<construction-factor1  > 
I  <construction-factor2> 
I  OPT<construction-term>  ; 
::=  <construction-factor1  >|<construction-factor2>; 
:.=  OBJECT_CLASS_ID_OF(ColumnFixed) 
I  OBJECT_CLASS_ID_OF(CompositeColumnFixed); 
<construction-factor2>  ::=  OBJECT_CLASSJD_OF(ArrangedContentFixed) 

I  OBJECT_CLASS_ID_OF{SourcedContentFixed); 


<construction-term> 
<following-term> 


<construction-type> 
<constructlon-factor1  > 


DEFINE(CompositeFloatGFS,  " 

<construction-expr>     :;=  SEQ(<construction-term1>  [<construction-term2>]...); 

<construction-term1  >    ::=  <(X)nstnjction-factor1>|<construction-factor2>; 
<construction-term2>    ;:=  <construction-term1> 

I  OPT<construction-tactor1>; 
<construction-f acton >  ::=  OBJECT_CLASSJD_OF{BasicColumn) 

I  OBJECT_CLASS_ID_OF(CompositeFixtureVariable) 

I  OBJECT_CLASSJD_OF{TableArea); 
<cx)nstruction-factor2>  ;:=  OBJECT_CLASS_ID_OF(ArrangedContentVariable) 

I  OBJ ECT_CLASSJD_OF{SourcedContent Variable); 

DEFINE{CompositeColumnGFS.  " 
<construction-expr>     ::=  <construction-term> 

I  <construction-type> 

1  SEQ(<construction-term>  <construction-footnote>) 
I  SEQ(<construction-type>  <construction-footnote>); 

<construction-term>     ::=  <construction-factor1  > 

I  OPT  <cx)nstruction-factor1> 
I  REP  <construction-factor1> 
I  OPT  REP  <construction-tactor1>; 
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<construction-type>     ::=  SEQ({<construction-term>  |  <construction-factor2>}...) 

I  CHO({<construction-term>}...); 

<construction-factor1>  ::=  OBJECT_CLASS_ID_OF(BasicFloat) 

I  OBJECT_CLASS_ID_OF(TableArea) 
I  OBJECT_CLASS_ID_OF(CompositeFloat) 
I  OBJECT_CLASS_ID_OF(CompositeFixture Variable) 
I  OBJECT_CLASSJD_OF(FootnoteArea) 
I  <construction-type>; 

<constnjction-footnote>  ::=  OBJECT_CLASS_ID_OF(FootnoteArea) 

I  OPT  OBJECT_CLASS_ID_OF(FootnoteArea); 
<construction-f actor2>  :  ;=  OBJECT_CLASS_l  D_OF(ArrangedContentVariable) 

I  OBJECT_CLASS_ID_OF(SourcedContentVariable); 

") 


DEFINE(CompositeColumnVariableGFS.  "$CompositeColumnGFS") 


DEFINE(CompositeColumnFixedGFS,  "$CompositeColumnGFS") 


DEFINE(CompositeFixtureGFS.  " 
<construction-expr>     ::=  <cx)nstruction-factor> 

I  REP  CHO(<construction-factor>...); 

<construction-factor>    ::=  OBJECT_CLASS_ID_OF(BasicFloat) 

I  OBJECT_CLASS_l D_OF(FootnoteArea) 
I  OBJECT_CLASS_ID_OF(ComposrteArtwoil<) 
I  OBJECT_CLASS_ID_OF(FomiArea); 

") 


DEFINE(CompositeFixtureFixedGFS.  "$CompositeFixtureGFS") 


DEFINE(CompositeFixtureVariableGFS.  "$CompositeFixtureGFS") 


DEFINE(CompositeArtworkGFS.  " 

<construction-expr>  ::=  REP  OBJECT_CLASSJD_OF(BasicFixture); 
") 


DEFINE(TableAreaGFS.  " 
<cx>nstruction-expr>     ::=  <row-area> 

I  SEQ([<table-header>]  (<table-label>]  <row-area>[<table-label>l); 
<table-header>  ::=  OBJECT_CLASS_ID_OF(TableHeader); 

<table-label>  ::=  OBJECT_CLASS_ID_OF(Tab!eLabel); 

<row-area>  ::=  REP  OBJECT_CLASS_ID_OF(RowArea) 

I  REP  CHO(OBJECT_CLASS_ID_OF(RowArea)...); 

••) 

DEFINE(RowAreaGFS." 
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<construction-expr>     ::=  SEQ(OBJECT_CLASS_ID_OF(Cell)...) 

I  SEQ(OBJECT_CLASSJD_OF(Cell) 

OBJECT_CLASS_ID_OF(SubRowGroup)); 

") 


DEFINE(SubRowGroupGFS." 

<construction-expr>  ::=  REP  OBJECT_CLASS_ID_OF{SubRow); 
") 


DEFINE(SubRowGFS." 

<constaiction-expr>  ::=  SEQ(OBJECT_CLASSJD_OF(Cell)...); 
") 


DEFINE(TableHeaderGFS," 

<construction-expr>     ::=  SEQ(OBJECT_CLASS_ID_OF(SourcedContentFixed)...); 


DEFINE(TableLabelGFS." 

<construction-expr>     ::=  SEQ(OBJECT_CLASS_ID_OF(TableLabelContent)...) 

I  SEQ(OBJECT_CLASSJD_OF(TableLabelContent) 
OBJECT_CLASS_ID_OF{CompositeTableLabel)); 

") 

DEFINE(ComposrteTableLabelGFS," 

<construction-expr>  ;:=  SEQ(OBJECT_CLASS_ID_OF(LabelComponent).. ); 
") 


DEFINE(LabelComponentGFS," 

<construction-expr>  ::=  SEQ(OBJECT_CLASS_ID_OF(TableLabelContent) ..); 
") 


DEFINE(FormAreaGFS." 
<constmction-expr>     ::=  AGG(<factor>...); 

<factor>  ::=  OBJECT_CLASS_ID_OF(ArrangedContentFixed) 

I  OBJECT_CLASS_ID_OF(FormEntryArea) 
I  OBJECT_CLASS_ID_OF(EntryGroupArea); 

")  . 


DEFINE(EntryGroupAreaGFS."$FormAreaGFS") 


7.4.2  Factor  constraints 


7.4.2.1  FACTOR  ANY-LAYOUT 
{ 

GENERIC: 
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REQ  Object-type 

REQ  Object-class-identifier 
SPECIFIC: 

PERM  Object-type 

REQ  Object-identifier 

CASE  $DAC  OF  { 

$FDA:  PERM  Object-class 
$FPDA:  REQ  Object-class 
}. 

REQ  Subordinates 
SPECIFIC_AND_GENERIC: 

PERM  User-readable-comments 
PERM  User-visible-name 

} 


{VIRTUAL}, 
{ANY_VALUE} 

{VIRTUAL}, 
{ANY_VALUE}, 

{VIRTUAL} 
{VIRTUAL} 

{VIRTUAL} 

{ANY_STRING}, 
{ANY_STRING} 


7.4.2.2  FACTOR  ANY-PAGE 

:ANY-LAYOUT  { 
GENERIC: 

REQ  Object-type 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Generator 
PERM  Bindings 


} 

SPECIFIC: 
PERM 
REQ 


Object -type 
Subordinates 


SPECIFIC_AND_GENERIC : 
PERM  Dimensions 
PERM  Transparency 
PERM  Colour 
PERM  Page-position 

} 


{•page- 


for-subordinates  {$PageGFS}, 
{PMUL  {SSPECIFYBINDINGS}, 

PERM  {$INITIALISEPGNUMBER.$USEPGNUMBERS}} 


{'page'}, 

{SUBJD_OF(BasicHeader), 

SUBJD_OF(CompositeHeader), 

SUBJD_OF(BasicBody), 

SUB_ID_OF(FixedCompositeBody), 

SUB_ID_OF(VariableCompositeBody), 

SUB_ID_OF(BasicFooter), 

SUBJD_OF(CompositeFooter)} 

{$PermissiblePageDimensions}, 
{ANY_VALUE}, 
{ANY  VALUE}, 
{ANY_VALUE} 


7.4.2.3  FACTOR  ANY-FRAME-FIXED 

:ANY-LAYOUT  { 
GENERIC: 

REQ  Object-type  {'frame'} 
SPECIFIC: 

PERM   Object-type  {'frame'} 
SPECIFIC_AND_GENERIC : 
PERM  Position 


{REQ  #fixed-position 
{REQ  #horizontal-position 


{ANY_VALUE}, 
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PERM  Dimensions 


PERM  Transparency 
PERM  Colour 
PERM  Border 


REQ  #vertical-position 

{REQ  #horizontal-dimension 
{REQ  #fixed-dimension 
REQ  #verlical-dimension 
{REQ  #fixed-dimension 

{ANY_VALUE}. 

{ANY_VALUE}. 

{ANY_VALUE} 


{ANY_VALUE}}}. 

{ANY_VALUE}). 

{ANY_VALUE}}}. 


7.4.2.4  FACTOR  ANY-FRAME-VARIABLE 


:ANY-LAYOUT  { 
GENERIC: 

REQ  Object-type 
SPECIFIC: 

PERM  Object-type 

CASE  $DAC  OF  { 
$FPDA: 

REQ  Position 


REQ  Dimensions 


SPECIFIC,  AND_GENERIC: 
CASE  $DAC  OF  { 
$FDA: 

PERM  Position 


PERM  Dimensions 


}. 

PERM  Transparency 

PERM  Colour 

PERM  Border 


{'frame'} 
{'frame'}, 


{REQ  #fixed-position 

{REQ  #horizontal-position 

REQ  #vertical-position 
{REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}. 
REQ  #vertical-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}} 


{ANY_VALUE}. 
{ANY_VALUE}}}. 


{REQ  #tixed-position 

{REQ  #horizontal-position 
REQ  #vertical-position 
{REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}, 
REQ  #vertical-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}} 

{ANY_VALUE}. 
{ANY_VALUE}. 
{ANY_VALUE} 


{ANY_VALUE}, 
{ANY_VALUE}}}. 
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7.4.3  Ck>nstituent  constraints 


7.4.3.1  DocumentLayoutRoot 

:ANY-LAYOUT{ 
GENERIC: 

REQ  Object-type  {document-layout-root}, 
CASE  $DAC  OF  { 
$PDA-FPDA:  . 

REQ   Generator-for-subordinates  {$DocLayRootGFS}, 
PERM  Bindings  {PMUL  {$SPECIFYBINDINGS}, 

PERM  {SINITIALISEPGNUMBER}} 

}. 

REQ    Application-comments         {REQ  #constraint-name  {"0"}. 

PERM  #extemal-data  {ANY_VALUE}} 

SPECIFIC. 

PERM  Object-type  {'document-layout-root'}, 
CASE  $DAC  OF  { 
$FDA: 

PERM   Object-class  {OBJECT_CLASS_ID_OF 

(DocumentLayoutRoot)} 

$FPDA; 

REQ    Object-class  {OBJECT_CLASS_ID_OF 

(DocumentLayoutRoot)} 

}. 

REQ    Subordinates  {SUBJD_OF(PageSet)+}, 
PERM   Application-comments        {REQ  #constraint-name  {"0"}. 

PERM  #external-data  {ANY_VALUE}} 

} 


7.4.3.2  PageSet 


:ANY-LAYOUT  { 
GENERIC: 

REQ  Object-type 


{'page-set'}. 


CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Generator-for-subordinates 


PERM  Bindings 


{$PageSetGFS}. 


REQ  Application-comments 

SPECIFIC: 

PERM  Object-type 
CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object-class 


{PMUL  {SSPECIFYBINDINGS}, 
PERM  {SINITIALISEPGNUMBER}} 

{REQ  #constraint-name  {"1"}, 
PERM  #external-data  {ANY_VALUE}} 

{'page-set'}. 


{OBJECT_CLASS_ID_OF(PageSet)} 
{OBJECT_CLASS_ID_OF(PageSet)} 
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REQ  Subordinates 


PERM  Application-comments 


(SUBJD_OF(Page)+, 

SUBJD_OF(RectoPage)+, 

SUB_ID_OF(VersoPage)+}. 
{REQ  #constraint-name  {"1"}. 

PERM  #extemal-data  {ANY_VALUE}} 


7.4.3.3  Page 

:ANY-PAGE  { 
GENERIC: 

REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 
$FPDA: 

REQ  Object-class 

}. 

PERM  Application-comments 

SPECIFIC_AND_GENERIC : 
PERM  Medium-type 


) 


{REQ  #constraint-name  {"2"}, 
PERM  #extemal-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF(Page)} 

{OBJECT_CLASS_ID_OF{Page)} 

{REQ  #constraint-name  {"2"}, 
PERM  #extemal-data  {ANY_VALUE}} 

{PERM  #nominal-page-size  {$NominalPageSizes} 
PERM  #side-of-sheet  {ANY_VALUE)} 


7.4.3.4  RectoPage 

ANY-PAGE  { 
GENERIC: 

REQ  Application-comments 

REQ  Medium-type 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 
$FPDA: 

REQ  Object-class 

}. 

PERM  Application-comments 
PERM  Medium-type 


{REQ  #constraint-name  ("3"}, 
PERM  #extemal-data  {ANY_VALUE}}. 

{PERM  #nominal-page-size  {$NominalPageSizes}, 
REQ  #side-of-sheet  {'rectoTunspecified'}} 


{OBJECT_CLASS_ID_OF{RectoPage)} 
{OBJECT_CLASS_ID_OF(RectoPage)} 

{REQ  #constraint-name  {"3"}, 
PERM  #extemal-data  { AN Y_ VALUE}}. 

{PERM  #nominal-page-size  {$NominalPageSizes}, 
PERM  #side-ot-sheet  {  rectoTunspecified  }} 
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7.4.3.5  VersoPage 


:ANY-PAGE  { 
GENERIC: 

REQ    Application-comments         {REQ  #constraint-name  {"4"}. 

PERM  #extemal-data  {ANY_VALUE}}, 
REQ    Medium-type  {PERM  #nominal-page-size  {$NominalPageSizes}. 

REQ  #side-of-sheet  {'verso Tunspecitied'}} 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class  {OBJECT_CLASSJD_OF(VersoPage)} 
$FPDA: 

REQ  Object-class       {OBJECT_CLASS_ID_OF{ VersoPage)} 

}. 

PERM   Application-comments        {REQ  #constraint-name  {"4"}, 

PERM  #external-data  {ANY_ VALUE}}, 

PERM   Medium-type  {PERM  #nominal-page-size  {$NominalPageSizes}, 

PERM  #side-ot-sheet{'verso Tunspecitied'}} 

} 


7.4.3.6  CompositeHeader 

:ANY-FRAME-FIXED  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ    Generator-for-subordinates  {$HeaderFooterGFS}}, 
PERM   Layout-path  {'ayO-degrees  - H/F  layouts  A1.B2 - 

ri80-degrees'  -  H/F  layout  81  - 
I'O-degrees'  -  H/F  layout  A2  -}, 
REQ    Application-comments         {REQ  #constraint-name  { '5'  }, 

PERM  #extemal-data  {ANY_VALUE}} 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-Class  {OBJECT_CLASSJD_OF(CompositeHeader)} 

$FPDA: 

REQ  Object-class  {OBJECT_CLASS_ID_OF(CompositeHeader)} 

}. 

REQ    Subordinates  {SUB_ID_OF(SourcedContentFixed)-H, 

SUB_ID_OF(ArrangedContentFixed)-H, 
SUBJD_OF(SourcedContentVariable)+, 
SUB_I  D_OF(ArrangedContent  Variable)-!-} . 

PERM    Imaging-order  {SUBJD_OF(SourcedContentFixed)+, 

SUB_ID_OF(ArrangedContentFixed)-t-}, 

PERM   Application-comments        {REQ  #constraint-name  {"5'}, 

PERM  #external-data  {ANY_VALUE}} 

} 
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7.4.3.7  ComposlteFooter 


:ANY-FRAME-F1XED  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 
REQ 

PERM  Layout-path 


REQ  Application-comments 


Generator-for-subordinates  {$HeaderFooterGFS}}, 
{•270-degrees"  ~  H/F  layouts  A1.B2  - 
ri80-degrees"  -  H/F  layout  B1  - 
|  0-degrees°  -  H/F  layout  A2  -}. 
{REQ  #constraint-name  {"32"}. 
PERM  #extemal-data  {ANY_VALUE}} 


SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class  {OBJECT_CLASS_ID_OF(CompositeFooter)} 

$FPDA: 

REQ   Object-class  {OBJECT_CLASSJD_OF(CompositeFooter)} 


REQ  Subordinates 


PERM  Imaging-order 
PERM  Application-comments 


{SUB_ID_OF(SourcedContentFixed)-f-, 
SUBJD_OF(ArrangedContentFixed)+. 
SUB_I  D_OF(SourcedContent  Variable)+ . 
SUBJD_OF(ArrangedContentVariable)-H}. 
{SUB_ID_OF(SourcedContentFixed)-(-, 
SUB_ID_OF(ArrangedContentFixed)+}. 
{REQ  #constraint-name  {"32"}. 
PERM  #extemal-data  {ANY_VALUE}} 


7.4.3.8  FixedCompositeBody 

:ANY-FRAME-FIXED  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Generator-for 
PERM  Layout-path 


}. 

REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 


$FPDA: 


REQ  Object-class 


REQ  Subordinates 


subordinates  {$FixedCompositeBodyGFS}, 
{'270-degrees'  ~  body  layout  A  - 
I'O-degrees'  -  body  layout  B  - 
ri80-degrees'  -  body  layout  C  -} 

{REQ  #constraint-name  {"6"}. 
PERM  #extemal-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF 

(FixedCompositeBody)} 

{OBJECT_CLASSJD_OF 

(FixedCompositeBody)} 

{SUB_ID_OF(CompositeCommon)-t-. 
SUB_ID_OF(BasicFixture)+. 
SUB_ID_OF(ColumnFixed)-(-. 
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PERM  Imaging-order 


PERM  Application-comments 


SUB_ID_OF(CompositeFixtureFjxed)+, 
SUBJD_OF(VariableCompositeBody)+. 
SUB_ID_OF(SourcedContentFixed)+, 
SUB_ID_OF(ArrangedContentFixed)+}, 
{SUBJD_OF(CompositeCommon)+, 
SUBJD_OF(BasicFixture)+, 
SUBJD_OF(ColumnFixed)+, 
SUBJD_OF(CompositeFixtureFixed)+, 
SUB_ID_OF(VariableCompositeBody)+. 
SUB_ID_OF(SourcedContentFixed)+. 
SUB_ID_OF(ArrangedContentFixed)+}, 
{REQ  #constraint-name  {"6"}, 
PERM  #extemal-data  {ANY_VALUE}} 


7.4.3.9  VariableCompositeBody 


.ANY-FRAME-FIXED  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Generator-for- 
PERM  Layout-path 


REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 


$FPDA: 


REQ  Object-class 


REQ  Subordinates 


PERM  Application-comments 


subordinates  {$VariableCompositeBodyGFS}, 
{'270-degrees'  -  tx)dy  layout  A  - 
I'O-degrees'  -  body  layout  B  - 
l'180-degrees'  -  tx)dy  layout  C  -} 

{REQ  #constraint-name  {"7"}, 
PERM  #external-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF 

(VariableCompositeBody)} 

{OBJECT_CLASSJD_OF 

(VariableCompositeBody)} 

{SUBJD_OF(SnakingColumns)+. 
SUB_ID_OF(SynchronizedColumns)+. 
SUBJD_OF(BasicFloat)+, 
SUBJD_OF(FootnoteArea)+, 
SUBJD_OF(CompositeFloat)-i-, 
SUBJD_OF(CompositeFixtureVariable)+. 
SUBJD_OF(TableArea)-h, 
SUBJD_OF(ArrangedContentVariable)-H, 
SUBJD_OF(SourcedContentVariable)+}. 

{REQ  #constraint-name  {"7"), 
PERM  #extemal-data  {ANY_VALUE}} 
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7.4.3.10  ColumnFixed 


:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
SPDA-FPDA: 

REQ  Position 


{REQ  #fixed-positlon 

{REQ  #horizontal-position  {ANY_VALUE}. 
REQ  #vertical-position  {ANY_VALUE}}}. 
CASE  SUPERIOR  ({VariableCompositeBody 

I  FixedComposlteBody}  (Layout-path))  OF  { 

{■270-degrees'}:  --  body  layout  A 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {  applies*}}. 
REQ  #vertical-dimension 
{REQ  #rule-b  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}}, 

PERM  Layout-path  {•270-degrees'} 

{'0-degrees'}:  -  body  layout  B  - 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #mle-b  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}, 
REQ  #vertical-dimension 
{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}}. 

REQ  Layout-path  {'O-degrees'} 


}  }. 


{'180-degrees'}:  -  tx)dy  layout  C  - 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #maximum-size  {'applies'}}. 
REQ  #vertical-dimension 
{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #nnaximum-size  {'applies'}}}, 

REQ  Layout-path  {'180-degrees'} 


REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object-class 

}. 

REQ  Subordinates 
PERM  Imaging-order 
PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Permitted-categories 


{REQ  #constraint-name  {"8"}, 
PERM  #external-data  {ANY_VALUE}} 


{OBJECT_CLASSJD_OF(ColumnFixed)} 

{OBJECT_CLASS_ID_OF(ColumnFixed)} 

{SUB_ID_OF(SpecificBlock)+}. 
{SUBJD_OF(SpecificBlock)-H}. 
{REQ  #constraint-name  {"8"}. 
PERM  #extemal-data  {ANY_VALUE}} 

{ANY_STRING...} 
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7.4.3.1 1  ColumnVariable 


ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Position 


{REQ  #variable-position  { 

PERM  #offset  (ANY_VALUE}, 
PERM  #separation  {ANY_VALUE}. 
PERM  #alignment  {ANY_VALUE}. 
PERM  #fill-order  {'normal-order'}}}, 
CASE  SUPERIOR  (VariableCompositeBody(Layout-path))  OF  { 


{'270-degrees'}:  -  body  layout  A  - 


REQ  Dimensions 


PERM  Layout-path 


{'0-degrees'}: 
REQ 


-  body  layout  B  - 
Dimensions 


REQ  Layout-path 


(REQ  #horizontal-dimension 
{REQ  #fixed-dimension  {ANY_VALUE}}. 

REQ  #vertical-dimension 
{REQ  #rijle-b  {ANY_VALUE} 
|REQ  #maxlmum-size  {  applies*}}}, 

{'270-degrees'} 


{REQ  #horizontal-dimension 

{REQ  #rule-b  {ANY_VALUE} 

|REQ  #maximum-size  {'applies'}}, 

REQ  #vertical-dimension 

{REQ  #1ixed-dimension  {ANY_VALUE}}}, 
{'0-degrees'} 


{'180-degrees'}:  -  body  layout  C  - 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #njle-b  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}, 
REQ  #vertical-dimension 
{REQ  #tixed-dimension  {ANY_VALUE}}}, 

REQ  Layout -path  {'ISO-degrees'} 

}  }. 

REQ    Application-comments         {REQ  #constraint-name  {"9"}, 

PERM  #external-data  {ANY_VALUE}} 


SPECIFIC; 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object-class 

}. 

REQ  Subordinates 
PERM  Imaging-order 
PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Permitted-categories 

} 


{OBJECT_CLASS_ID_OF(ColumnVariable)} 

{OBJECT_CLASS_ID_OF(ColumnVariable)} 

{SUB_ID_OF(SpecificBlock)-(-}, 
{SUB^ID^OF(SpecificBlock)+}, 
{REQ  #constraint-name  {"9"}, 
PERM  #external-data  {ANY_VALUE}} 

{ANY_STRING...} 
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7.4.3.12  SnakingColumns 


:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ   Generator-for-subordinates  {SSnakingColumnsGFS}, 
REQ  Position  {REQ  #variable-position  ( 

PERM  #offset  {ANY_VALUE}. 

PERM  #separation  {ANY_VALUE}. 

PERM  #alignment  {ANY_VALUE}. 

PERM  #fjll-order  {  normal-order  }}}, 
PERM  Balance  {ANY_VALUE}, 

CASE  SUPERIOR  (VariableCompositeBody(Layout-path))  OF  { 


{■270-degrees'}:  --  body  layout  A  -- 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_ VALUE} 
|REQ  #maximum-size  {"applies"}}, 
REQ  #vertical-dimension 
{REQ  #rijle-b  {ANY_VALUE}}}. 
{'0-degrees'ri80-degrees"} 


REQ  Layout-path 


{'0-degrees'}: 
REQ 


-  body  layout  B  - 
Dimensions 


PERM  Layout-path 


{REQ  #hori2ontal-dimension 
{REQ  #rule-b  {ANY_VALUE)}, 
REQ  #vertical-dimension 
{REQ  #1ixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {"applies"}}}, 

{"90-degrees'r270-degrees"} 


{"ISO-degrees"};  -  body  layout  C  - 

REQ  Dimensions        {REQ  #horizontal-dimension 
,       :  {REQ  #rule-b  {ANY_VALUE}}. 

REQ  #vertical-dimension 
{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #maxlmum-size  {"applies"}}}. 
{■270-degrees'} 


PERM  Layout-path 


}  }. 

REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-Class 

$FPDA: 

REQ  Object-class 

}. 

REQ  Subordinates 


PERM  Application-comments 


{REQ  #constraint-name  {"10"}, 
PERM  #extemal-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF(Snakingcolumns)} 

{OBJECT_CLASS_ID_OF(Snakingcolumns)} 

{SUB_ID_OF(ColumnVariable)-t-, 
SUB_ID_OF(CompositeColumnVariable)-i-. 
SUB_ID_OF(ArrangedContentVariable)-^, 
SUB_ID_OF(SourcedContentVariable)+}. 
{REQ  #constraint-name  {"10"}, 
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PERM  #external-data  {ANY_VALUE}} 


7.4.3.13  SynchronizedColumns 

:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Generator-for-subordinates  {$SynchronizedColumnsGFS}, 
REQ    Position  {REQ  #variable-position  { 

PERM  #offset  {ANY_VALUE}, 
PERM  #separation  {ANY_VALUE}, 
PERM  #alignment  {ANY_VALUE}. 
PERM  #f ill-order  {'normal-order'}}}, 

CASE  SUPERIOR  (VariableCompositeBody(Layout-path))  OF  { 


{'270-degrees'}:  -  body  layout  A  - 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}, 
REQ  #vertical-dimension 
{REQ  #rule-b  {ANY_VALUE}}}, 
{•270-degrees'} 


PERM  Layout-path 


{'0-degrees'}:  -  body  layout  B  - 
REQ  Dimensions 


REQ  Layout-path 


{REQ  #horizontal-dimension 
{REQ  #rule-b  {ANY_VALUE}}, 
REQ  #vertical -dimension 
{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}}, 

{'0-<Jegrees'} 


{'180-degrees'}:  -  body  layout  C  - 

REQ  Dimensions       {REQ  #horizontal-dimension 

{REQ  #fule-b{ANY_VALUE}}. 
REQ  #vertical-dimension 
{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}}, 
REQ  Layout-path  {'180-degrees'} 

}  }. 

REQ    Application-comments         {REQ  #constraint-name  {"11"}, 

PERM  #external-data  {ANY_VALUE}} 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class  {OBJECT_CLASSJD_OF(SynchronizedColumns)} 

$FPDA: 

REQ  Object-class  {OBJECT_CLASS_ID_OF(SynchronizedColumns)} 

}. 

REQ    Subordinates  {SUBJD_OF(ColumnFixed)-h, 

SUBJD_OF(ComposlteColumnFixed)-^, 
SUBJD_OF(ArrangedGontentFixed)-i-, 
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SUBJD_OF(SourcedContentFixed)+}, 
PERM    Application-comments        {REQ  #constraint-name  {"1 1"), 

PERM  #extemal-data  {ANY_VALUE}} 


7.4.3.14  BasicFloat 

:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ   Position  {REQ  #variable-position  { 

PERM  #offset  {ANY_VALUE}, 
PERM  #separation  {ANY_VALUE}, 
PERM  #alignment  {ANY_VALUE}. 
PERM  #fill-order  {'normal-order'}}}, 

CASE  SUPERIOR  ({VariableCompositeBody 

I  CompositeColumnVariable  |  CompositeColumnFixed 

I  ComposrteFixtureVariable  |  CompositeFixtureFixed}  (Layout-path))  OF  { 

{'270-degrees'};  -  body  layout  A  -  * 
REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}, 
REQ  #vertical-dimension 
{REQ  #rule-b  {ANY_VALUE}}}. 
PERM  Layout-path  {'270-degrees'} 

{'0-degrees'}:  -  body  layout  B  - 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #rule-b  {ANY_VALUE}}, 
REQ  #vertical-dimension 
{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}}, 

REQ  Layout-path  {'0-degrees'} 

{'180-degrees'}:  --  body  layout  C  - 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #mle-b  {ANY_VALUE}}. 
REQ  #verlical-dimension 
{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}}. 

REQ  Layout-path  {'ISO-degrees'} 

}  }. 

REQ    Application-comments         {REQ  #constraint-name  {"12"}, 

PERM  #external-data  {ANY_VALUE}} 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class  {OBJECT_CLASS_ID_OF(BasicFloat)} 

$FPDA: 

REQ   Object-class  {OBJECT_CLASS_ID_OF{BasicFloat)} 

}. 
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REQ  Subordinates 
PERM  Imaging-order 
PERM  Application-comments 

SPECIFIC.  AND_GENERIC : 
PERM  Permitted-categories 


{SUB_ID_OF(SpecificBlock)+}. 
{SUBJD_OF(SpecificBlock)+}. 
{REQ  #constraint-name  {"12"}. 
PERM  #extemal-data  {ANY_VALUE}} 

{ANY_STRING...} 


7.4.3.15  CompositeFloat 

:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA. 
REQ 
REQ 


Generator-for-subordlnates  {$CompositeFloatGFS}, 
Position  {REQ  #variable-position  { 

PERM  #offset  {ANY_VALUE}, 
PERM  #separation  {ANY_VALUE}, 
PERM  #alignment  {ANY_VALUE}. 
PERM  #fill-order  {'normal-order'}}}. 


CASE  SUPERIOR  {VariableCompositeBody(Layout-path))  OF 


{■270-degrees*}:  --  body  layout  A  -- 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}, 
REQ  #vertical-dimension 
{REQ  #rule-a  {ANY_VALUE}}}. 
{'0-degrees 'I'lSO-degrees'} 


PERM  Layout-path 


{'O-degrees'}:  -  body  layout  B 
REQ  Dimensions 


REQ  Layout-path 


{REQ  #horizontal-dimension 
{REQ  #rule-a  {ANY_VALUE}}, 
REQ  #vertical-dimension 
{REQ  #tixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}}. 

{'90-degrees'|'270-degrees'} 


{'180-degrees'}:  -  body  layout  C  - 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #rule-a  {ANY_VALUE}}. 
REQ  #vertical-dimension 
{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}}. 
{'90-degrees  r270-degrees'} 


REQ  Layout-path 
}  }. 

REQ  Application-comments 


SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-Class 

$FPDA; 


{REQ  #constraint-name  {"13"}, 
PERM  #external-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF(CompositeFloat)} 
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REQ   Object-class  {OBJECT_CLASSJD_OF(CompositeFloat)} 


REQ  Subordinates 


PERM  Application-comments 


{SUB_ID_OF(CompositeFlxtureVariable)+, 
SUB_ID_OF(TableArea)+, 
SUB_ID_OF(BasicColumn)+. 
SUB_ID_OF(ArrangedContentVariable)+, 
SUBJD_OF(SourcedContent  Variable )+}. 
{REQ  #constraint-name  {"13"}, 
PERM  #extemal-data  {ANY_VALUE}} 


7.4.3.16  BasicColumn 


:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Positton 


{REQ  #variable-position  { 

PERM  #offset  {ANY_VALUE}. 
PERM  #separation  {ANY_VALUE}. 
PERM  #alignment  {ANY_VALUE}. 
PERM  #fill-order  {'normal-order'}}}, 


CASE  SUPERIOR  (VariableCompositeBody(Layout-path))  OF  { 

{'270-degrees  }:  -  txjdy  layout  A  ~ 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #mle-b  {ANY_VALUE}}. 
REQ  #vertical-dlmension 
{REQ  #tixed-dimension  {ANY_VALUE} 
|REQ  #rule-b  {ANY_VALUE} 
|REQ  #maximum-size{  applies'}}}, 
{•270-degrees'} 


PERM  Layout-path 


{'0-degrees'}: 
REQ 


--  body  layout  B 
Dimensions 


REQ  Layout-path 


{REQ  #horizontal-dimension 
{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #rule-b  {ANY_VALUE} 
|REQ  #maximum-si2e{'applies'}}. 
REQ  #vertical-dimension 
{REQ  #tixed-dimension  {ANY_VALUE} 
|REQ  #rule-b  {ANY_VALUE}}}, 

{'0-degrees'} 


{'180-degrees'}:  --  body  layout  C  - 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #rule-b  {ANY_VALUE} 
|REQ  #maximum-size{'applies'}}. 
REQ  #vertical-dimension 
{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #mle-b  {ANY_VALUE}}}. 
{'180-degrees'} 


REQ  Layout-path 
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}  }. 

REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object-class 

}. 

REQ  Subordinates 

PERM  Application-comments 

SPECIFIC,  AND_GENERIC: 
PERM  Permitted-categories 

} 


{REQ  #constraint-name  {"14"}, 
PERM  #extemal-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF(BasicColumn)} 

{OBJECT_CLASS_ID_OF(BasicColumn)} 

{SUB_ID_OF(SpecificBlock)+}, 
{REQ  #constraint-name  {"14"}, 
PERM  #extemal-data  {ANY_VALUE}} 

{ANY_STRING  ..} 


7.4.3.17  FootnoteArea 

:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ   Position  {REQ  #variable-position  { 

PERM  #offset  {ANY_VALUE}, 
PERM  #separation  {ANY_VALUE}, 
PERM  #allgnment  {ANY_VALUE}, 
PERM  #till-order  {'reverse-order'}}}, 

CASE  SUPERIOR  ({VariableCompositeBody 

I  CompositeColumnVariable  |  CompositeColumnFixed 

I  CompositeFixtureVariable  |  CompositeFlxtureFixed}  (Layout-path))  OF  { 

{'270-degrees'}:  -  body  layout  A  - 

REQ   Dimensions       {REQ  #horizontal-dimension 

{REQ  #1ixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}, 
REQ  #vertical-dimension 
{REQ  #rule-b  {ANY_VALUE}}}. 
PERM  Layout-path  {•270-degrees'} 

{'0-degrees'}:  -  body  layout  B  - 

REQ   Dimensions       {REQ  #horizontal-dimension 

{REQ  #rule-b  {ANY_VALUE}}. 
REQ  #vertical-dimension 
{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}}, 

REQ   Layout-path  {'0-degrees'} 

{•180-degrees'}:  -  body  layout  C  - 

REQ   Dimensions       {REQ  #horizontal-dimension 

{REQ  #mle-b  {ANY_VALUE}}, 
REQ  #verlical-dimension 
{REQ  #fixed-dimenslon  {ANY_VALUE} 
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|REQ  #maximum-size  {"applies"}}}. 
REQ   Layout-path  {'180-degrees"} 

}  }. 

REQ    Permitted-categories  {$FOOTNOTECATEGORY}. 
--  For  example, 

For  CompositeBody  "Footnote-1" 
For  SnakingColumns  "Footnote-2" 
For  SynchronizedColumns      "Footnote-3".  "Footnote-4'', 

"Footnote-5" 

For  CompositeFixture  "Footnote-6" 


REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object-class 

}. 

REQ  Subordinates 

PERM  Permitted-categories 

PERM  Application-comments 


{REQ  #constraint-name  {"15"}, 
PERM  #extemal-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF(FootnoteArea)} 

{OBJECT_CLASS_ID_OF(FootnoteArea)} 

{SUB_ID_OF(SpeciticB!ock)+}, 
{$FOOTNOTECATEGORY}, 
{REQ  #constraint-name  {"15"}, 
PERM  #external-data  {ANY_VALUE}}} 


7.4.3.18  ArrangedContentFixed 


ANY-FRAME-FIXED  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Generator-tor-subordinates  {<construction-expr>::= 

SEQ(OBJECT_CLASS_ID_OF(GenericBlock). ..)}}. 
{REQ  #constraint-name  {"16"}, 
PERM  #external-data  {ANY_VALUE}} 


REQ  Application-comments 


SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 


$FPDA: 


REQ  Object-class 


{OBJECT_CLASS_ID_OF 

(ArrangedContentFixed)} 

{OBJECT_CLASS_ID_OF 

(ArrangedContentFixed)} 


REQ  Subordinates 
PERM  Imaging-order 
PERM  Application-comments 


{SUBJD_OF(GenericBlock)-(-}. 
{SUBJD_OF(GenericBlock)-t-}, 
{REQ  #constraint-name  {"16"}, 
PERM  #external-data  {ANY_VALUE}} 
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7.4.3.19  ArrangedContentVariable 


REQ  Position 


:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ    Generator-for-subordinates  {<construction-expr>;:= 

SEQ(OBJECT_CLASS_ID_OF(GenericBlock)...)}, 
{REQ  #variable-position  { 

PERM  #offset  {ANY_VALUE}, 
PERM  #separation  {ANY_VALUE}, 
PERM  #alignment  {ANY_VALUE}, 
PERM  #fill-order  {'normal-order'}}}. 
REQ   Dimensions       {REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}, 
REQ  #vertical-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}} 


REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 


$FPDA: 


REQ  Object-class 


}. 


REQ  Subordinates 
PERM  Imaging-order 
PERM  Application-comments 


{REQ  #constraint-name  {"17"}, 
PERM  #external-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF 

(ArrangedContentVariable)} 

/OBJECT_CLASSJD_OF 

(ArrangedContentVariable)} 

{SUBJD_OF(GenericBlock)+}. 
{SUBJD_OF(GenericBlock)-i-}, 
{REQ  #constraint-name  {"17"}, 
PERM  #external-data  {ANY_VALUE}} 


7.4.3.20  SourcedContentFixed 


:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 
REQ 
REQ 


Logical -source 
Position 


REQ  Dimensions 


{OBJECT_CLASS_ID_OF(CommonContent)}, 
{REQ  #fixed-position 

{REQ  #horizontal-position  {ANY_VALUE}, 
REQ  #vertical-position  {ANY_VALUE}}}, 
{REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}, 

REQ  #vertical-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}}, 


CASE  SUPERIOR  ({CompositeHeader  |  CompositeFooter  |  TableHeader 
I  FixedCompositeBody  |  CompositeCommon 
I  SynchronizedColumns}  (Layout-path))  OF  { 
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{'270-degrees'}:  -  H/F  layout  A1  or  B2  when  the  immediate  superior  is 

CompositeHeader.  CompositeFooter  or  TableHeader,  or  -- 
--  body  layout  A  when  the  immediate  superior  is 
FixedCompositeBody.  CompositeCommon  or 
SynchronizedColumns  -- 
PERM  Layout-path      {'ayo-degrees'   -  H/F  layout  A1  or  body  layout  A  -- 

I'lSO-degrees'}  --  H/F  layout  82  - 

{'180-degrees'}:  --  H/F  layout  81  when  the  immediate  superior  is 

CompositeHeader  or  CompositeFooter,  or  -- 
--  body  layout  C  when  the  immediate  superior  is 
FixedCompositeBody.  CompositeCommon  or 
SynchronizedColumns  -- 
REQ  Layout-path       {•180-degrees  }  -  H/F  layout  81  or  body  layout  C  ~ 


{■  0-degrees'}:  -  H/F  layout  A2  when  the  immediate  superior  is 

CompositeHeader  or  CompositeFooter,  or  - 
-  t>ody  layout  B  when  the  immediate  superior  is 
FixedCompositeBody,  CompositeCommon  or 
SynchronizedColumns 
PERM  Layout-path      {  ^yo-degrees*    -  H/F  layout  A2  - 

I'O-degrees'}  -  body  layout  8  ~ 


}  }. 

REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 


$FPDA: 


REQ  Object-class 


}. 


REQ  Subordinates 

PERM  Application-comments 


{REG  #constraint-name  {"18"}. 
PERM  #extemal-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF 

(SourcedContentFixed)} 

{OBJECT_CLASS_ID_OF 

(SourcedContentFixed)} 

{SUBJD_OF(SpecrticBlock)+}. 
{REQ  #constraint-name  {"18"}. 
PERM  #external-data  {ANY_VALUE}} 


7.4.3.21  SourcedContentVariable 

ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Logical-source  {08JECT_CLASS_ID_OF(CommonContent)}. 
REQ  Position  {REQ  #variable-position  { 

PERM  #offset  {ANY_VALUE}. 

PERM  #separation  {ANY_VALUE}. 

PERM  #alignment  {ANY_VALUE}. 

PERM  #fill-order  {'normal-order'}}}. 

CASE  SUPERIOR  ({CompositeHeader  |  CompositeFooter  |  VariableCompositeBody 
I  CompositeColumnVariable  j  CompositeColumnFixed  |  CompositeCommon 
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I  SnakingColumns  |  CompositeFloat}  (Layout-path))  OF  { 


{'270-clegrees'}:  --  H/F  layout  A1  or  B2  when  the  immediate  superior  is 

CompositeHeader  or  Composite  Footer,  or  -- 
--  body  layout  A  when  the  immediate  superior  is 
VariableCompositeBody,  CompositeColumnVariable, 
CompositeColumnFixed  or  CompositeCommon,  or  -- 
--  t)Ody  layout  B  or  C  when  the  immediate  superior  is 
SnakingColumns  or  CompositeFloat  -- 
REO  Dimensions        {REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #rule-b  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}), 
REQ  #vertical-dimension 
{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #rule-b  {ANY_VALUE} 
IREQ  #maximum-size  {'applies'}}}, 
PERM  Layout-path      {'270-degrees'   -  H/F  layout  A1  or  tx)dy  layout  A 

I'leO-degrees'  -  H/F  layout  B2  or  body  layout  C 
I'O-degrees'}   -  t)ody  layout  B  - 


{'180-degrees'}:  -  H/F  layout  B1  when  the  immediate  superior  is 

CompositeHeader  or  CompositeFooter,  or  - 

-  body  layout  C  when  the  immediate  superior  is 
VariableCompositeBody,  CompositeColumnVariable, 
CompositeColumnFixed  or  CompositeCommon,  or  - 

-  body  layout  A  when  the  immediate  superior  is 
SnakingColumns  or  CompositeFloat  - 


REQ  Dimensions 


REQ  Layout-path 


{REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE} 

|REQ  #njle-b  {ANY_VALUE}}, 

REQ  #vertical-dimension 

{REQ  #fixed-dimension  {ANY_VALUE} 

|REQ  #rule-b  {ANY_VALUE} 

|REQ  #maximum-size  {'applies'}}}, 
{'180-degrees'  -  H/F  layout  B1  or  body  layout  C 
l'270-degrees'}  -  body  layout  A  - 


{■  0-degrees'}: 


-  H/F  layout  A2  when  the  immediate  superior  is 
CompositeHeader  or  CompositeFooter,  or  - 

-  body  layout  B  when  the  immediate  superior  is 
VahableCompositeBody,  CompositeColumnVariable, 
CompositeColumnFixed  or  CompositeCommon,  or  - 
~  body  layout  A  when  the  immediate  superior  is 
SnakingColumns  or  CompositeFloat  - 


REQ  Dimensions 


PERM  Layout-path 


{REQ  #horizontal-dimension 

{REQ  #1ixed-dimension  {ANY_VALUE} 

IREQ  #mle-b  {ANY_VALUE}} 

|REQ  #maximum-size  {'applies'}}, 

REQ  #vertical-dimension 

{REQ  #fixed-dimension  {ANY_VALUE} 

IREQ  #rule-b  {ANY_VALUE} 

|REQ  #maximum-size  {'applies'}}}, 
{'270-degrees'  -  H/F  layout  A2  or  body  layout  A 
I'O-degrees'}  -  body  layout  B  - 
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{'90-degrees'}: 


--  body  layout  B  when  the  immediate  superior  is 
SnakingColumns,  or  -- 

--  body  layout  B  or  C  when  the  immediate  superior  is 
Composite  Float  -- 


REQ  Dimensions 


PERM  Layout-path 


}  }. 


{REQ  #horizontal-dimension 
{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #rule-b  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}. 
REQ  #vertical-dimension 
{REQ  #1ixed-dimension  {ANY_VALUE} 
|REQ  #fule-b  {ANY_VALUE}}}. 
{'O-degrees'  --  body  layout  B  -- 
ri80-degrees'}  --  body  layout  C  -- 


REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 


$FPDA: 


REQ  Object-class 


REQ  Subordinates 

PERM  Application-comments 


{REQ  #constraint-name  {"19"}, 
PERM  #extemal-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF 

(SourcedContentVariable)} 

{OBJECT_CLASS_ID_OF 

(SourcedContentVariable)} 

{SUB_ID_OF(SpecificBlock)+}. 
{REQ  #constraint-name  {"19"), 
PERM  #external-data  {ANY_ VALUE}} 


7.4.3.22  CompositeFixtureVariable 

:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ   Generator-for-subordinates  {$CompositeFixtureVariableGFS), 

REQ   Position  {REQ  #variable-position  { 

PERM  #oftset  {ANY_VALUE}, 
PERM  #separation  {ANY_VALUE}. 
PERM  #alignment  {ANY_VALUE}, 
PERM  #fill-order  {  normal-order  )}}. 

CASE  SUPERIOR  (VariableCompositeBody(Layout-path))  OF  { 

{'270-degrees'}:  -  body  layout  A  -- 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #tixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies') 
|REQ  #mle-b  {ANY_VALUE}). 
REQ  #vertical-dimension 
{REQ  #fixed-dimension  {ANY_VALUE) 
|REQ  #rule-b  {ANY_VALUE}}}. 
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PERM  Layout-path  {'270-clegreesT180-degrees' 

I'O-degrees'} 


{'O-degrees'}:  --  body  layout  B 
REQ  Dimensions 


REQ  Layout-path 


{REQ  #horizontal-dimension 
{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #rule-b  {ANY_VALUE}}. 
REQ  #vertical-dimension 
{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'} 
|REQ  #mle-b  {ANY_VALUE}}}. 

{'O-degrees  r90-degrees' 

r270-degrees'} 


}  }. 


{'180-degrees'}:  -  body  layout  C  - 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #mle-b  {ANY_VALUE}}. 
REQ  #verlical-dimension 
{REQ  #fixed-dimension  {ANY_ VALUE} 
I  REQ  #maximum-size  {'applies'} 
|REQ  #rule-b  {ANY_VALUE}}}, 
{'1 80-degrees  r270-degrees'} 


REQ  Layout-path 


REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA; 

PERM  Object-class 


$FPDA; 


REQ  Object-class 


REQ  Subordinates 


PERM  Application-comments 


{REQ  #constraint-name  {"20"}. 
PERM  #extemal-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF 

(CompositeFixture  Variable)} 

{OBJECT_CLASS_ID_OF 

(CompositeFixtureVariable)} 

{SUBJD_OF(BasicFloat)-i-. 
SUBJD_OF(FootnoteArea)+, 
SUBJD_OF(CompositeArtwork)+, 
SUB_ID_OF(FormArea)-h}. 
{REQ  #constraint-name  {"20"}, 
PERM  #external-data  {ANY_VALUE}} 


7.4.3.23  CompositeFixturePixed 

:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Generator-for-subordinates  {SCompositeFixtureFixedGFS}, 
REQ   Position  {REQ  #fixed-position 

{REQ  #horizontal-position  {ANY_VALUE}. 
REQ  #vertical-position  {ANY_VALUE}}}. 
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CASE  SUPERIOR  (FixedCompositeBocly(Layout-path))  OF  { 


{'270-degrees'}:  --  body  layout  A  -- 

REQ  Dimensions        {REG  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}, 
REQ  #vertical-dimension 
{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #rule-b  {ANY_VALUE}}}. 
{'270-degrees'ri80-degrees* 
I'O-degrees'} 


PERM  Layout-path 


{'0-degrees'}: 
REQ 


--  body  layout  B 
Dimensions 


REQ  Layout-path 


{REQ  #horizontal-dimension 
{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #mle-b  {ANY_VALUE}}. 
REQ  #verticai -dimension 
{REQ  #1ixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}}, 

{'O-degrees'l'QO-degrees' 

r270-degrees'} 


{■180-degrees'}:  -  body  layout  C  - 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #tixed-dimension  {ANY_VALUE} 
|REQ  #rule-b  {ANY_VALUE}}, 
REQ  #vertical-dimension 
{REQ  #tixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}}, 
{'1 80-degrees'r270-degrees'} 


REQ  Layout-path 


}  }. 


REQ  Application-comments 

SPECIFIC: 

CASE$DACOF{ 
$FDA: 

PERM  Object-class 


$FPDA: 


REQ  Object-class 


REQ  Subordinates 


PERM  Application-comments 


(REQ  #constraint-name  {"21"}, 
PERM  #extemal-data  {ANY_ VALUE}} 


{OBJECT_CLASS_ID_OF 

(CompositeFixtureFixed)} 

{OBJECT_CLASS_ID_OF 

(CompositeFixtureFixed)} 

{SUB_ID_OF(BasicFloat)-e, 

SUB_ID_OF(FootnoteArea)-i-, 

SUB_ID_OF(Compostte  Artwork)-!-, 

SUBJD_OF(FormArea)-i-}. 
{REQ  #constraint-name  {"21"}, 

PERM  #extemal-data  {ANY_ VALUE}} 


7.4.3.24  BasicFixture 


:ANY-FRAME-VARIABLE 
GENERIC: 
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CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ   Position  {REQ  #fixecl-position 

{REQ  #horizontal-position  {ANY_VALUE}. 
REQ  #vertical-position  {ANY_VALUE}}}. 

-  Note  that  values  of  position  may  usually  be  "0"  for  overlapping  figure. 

REQ   Dimensions       {REQ  #fiorizontal-climension 

{REQ  #fixed-climension  {ANY_VALUE} 
|REQ  #rule-b  {ANY_VALUE}}, 
REQ  #vertical -dimension 
{REQ  #fixedKJimension  {ANY_ VALUE} 
|REQ  #rule-b  {ANY_VALUE}}}. 

CASE  SUPERIOR  ({FixedCompositeBody  |  CompositeArtworK}  (Layout-patfi))  OF  ( 

{'270-degrees'}:  --  body  layout  A  -- 

PERM  Layout-path      {  ^yO-degrees  l'ISO-degrees'} 

{'0-degrees'}:  -  t)ody  layout  B  - 

REQ  Layout-path  {'0-degreesT270-degrees'} 

{"ISO-degrees"}:  -  body  layout  C  - 

PERM  Layout-path  {"180-degrees"r270-degrees"} 

}  }. 

REQ    Application-comments         {REQ  #constraint-name  {"22"}. 

PERM  #external-data  {ANY_VALUE}} 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class  {OBJECT_CLASS_ID_OF(BasicFixture)} 

$FPDA: 

REQ   Object-class  {OBJECT_CLASS_ID_OF(BasicFixture)} 

}. 

REQ    Subordinates  {SUB_ID_OF(SpecificBlock)-h}. 
PERM   Application-comments        {REQ  #constraint-name  {"22"}. 

PERM  #external-data  {ANY_VALUE}} 

SPECIFIC_AND_GENERIC : 

PERM   Pemiitted-categories  {ANY_STRING...} 

} 


7.4.3.25  CompositeColumnFixeci 

:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Generator-for-subordinates  {$CompositeColumnFixedGFS}, 
REQ   Position  {REQ  #fixed-position 

{REQ  #horizontal-position  {ANY_VALUE}. 

REQ  #venical-position  {ANY_VALUE}}}, 

CASE  SUPERIOR  (VariableCompositeBody(Layout-path))  OF  { 
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{'270-degrees'}:  --  body  layout  A  -- 

REQ  Dimensions        {REQ  #horizontal-dinnension 

{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #maximum-si2e  {'applies'}}, 
REQ  #vertical-dimension 
{REQ  #mle-b  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}}, 
{•270-degrees'} 


PERM  Layout-path 


{'0-degrees'}: 
REQ 


--  body  layout  B 
Dimensions 


REQ  Layout-path 


{REQ  #hori2ontal-dimension 
{REQ  #rule-b  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}, 
REQ  #vertical-dimension 
{REQ  #tixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}}, 

{'O-degreesT 


{'180-degrees'}:  -  body  layout  C 


REQ  Dimensions 


REQ  Layout -path 

}  }. 

REQ  Application-comments 


{REQ  #horizontal-dimension 
{REQ  #maximum-size  {'applies'}}, 
REQ  #vertical-dimension 
{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}}, 

{'180-degrees'} 


SPECIFIC 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 


$FPDA: 


REQ  Object-class 


REQ  Subordinates 


PERM  Application-comments 


{REQ  #constraint-name  {"23"}, 
PERM  #external-data  {ANY_VALUE}} 


{OBJECT_CLASS_lD_OF 

(CompositeColumnFixed)} 

{OBJECT_CLASS_ID_OF 

(CompositeColumnFixed)} 

{SUBJD_OF(BasicFloat)-h, 

SUBJD_OF(CompositeFloat)-i-, 

SUB_ID_OF(FootnoteArea)-i-, 

SUBJD_OF{CompositeFixtureVariable)-i-, 

SUBJD_OF(TableArea)+, 

SUB_ID_OF(ArrangedContentVariable)-^, 

SUB_ID_OF(SourcedContentVariable)-i-}, 
{REQ  #constraint-name  {"23"}, 

PERM  #external-data  {ANY_VALUE}} 


7.4.3.26  CompositeColumnVariable 

:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 
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REQ  Generator-for-subordinates  {SCompositeColumnVariableGFS}, 

REQ    Position  {REQ  #variable-position  { 

PERM  #offset  {ANY_VALUE}, 
PERM  #separation  {ANY_VALUE}, 
PERM  #alignment  {ANY_VALUE}. 
PERM  #fill-order  {'normal-order'}}}, 

CASE  SUPERIOR  (VariableCompositeBody(Layout-path))  OF  { 

{'270-degrees'}:  --  body  layout  A  - 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}. 
REQ  #verlical-dimension 
{REQ  #mle-b  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}}, 

PERM  Layout-path  {'270-degrees'} 


{'0-degrees'}:  --  body  layout  B 
REQ  Dimensions 


REQ  Layout-path 


{REQ  #horizontal-dimension 

{REQ  #rule-b  {ANY_VALUE} 

|REQ  #maximum-size  {'applies'}}, 

REQ  #vertical-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}}, 
{'0-degrees'} 


{"ISO-degrees'}:  -  body  layout  C  - 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #rule-b  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}, 
REQ  #vertical-dimension 
{REQ  #fixed-dimension  {ANY_VALUE}}}, 
{'180-degrees'} 


REQ  Layout-path 
}  }. 

REQ  Application-comments 


SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 


$FPDA: 


REQ  Object-class 


REQ  Subordinates 


PERM  Application-comments 


{REQ  #constraint-name  {"24"}, 
PERM  #external-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF 

(CompositeColumnVariable)} 

{OBJECT_CLASS_ID_OF 

(CompositeColumnVariable)} 

{SUBJD_OF(BasicFloat)+. 

SUB_ID_OF(CompositeFloat)+, 

SUB_ID_OF(FootnoteArea)-t-, 

SUBJD_QF(CompositeFixtureVariable)+, 

SUB_ID_OF(TableArea)-H, 

SUB_ID_OF(ArrangedContentVahable)-h. 

SUB_ID_OF(SourcedContentVariable)-t-}, 
{REQ  #constraint-name  {"24"}, 

PERM  #external-data  {ANY_VALUE}} 
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7.4.3.27  Ck>mpositeCommon 

:ANY-FRAME-FIXED  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ    Generator-for-subordinates  {$CompositeCommonGFS}. 

CASE  SUPERIOR  (FixedCompositeBody(Layout-path))  OF  { 

{'270-degrees*}:  --  body  layout  A  -- 

PERM  Layout-path  {'270-degrees'} 

{'0-degrees'}:  -  body  layout  B  - 

PERM  Layout-path  {'O-degrees'} 

{■180-degrees'};  -  body  layout  C  - 

PERM  Layout-path  {'ISO-degrees'} 

}}. 

REQ    Application-comments         {REQ  #constraint-name  {"25"}, 

PERM  #extemal-data  {ANY_VALUE}} 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class  {OBJECT_CLASS_ID_OF(CompositeCommon)} 

$FPDA: 

REQ   Object-class  {OBJECT_CLASS_ID_OF(CompositeCommon)) 

}. 

REQ    Subordinates  {SUB_ID_OF(SourcedContentFixed)-h. 

SUB_ID_OF(ArrangedContentFixed)+, 

SUB_ID_OF(SourcedContentVariable)-i-. 

SUB_I  D_OF(  ArrangedContent  Variable)+} , 
PERM   Imaging-order  {SUB_ID_OF(SourcedContentFixed)+, 

SUB_ID_OF(ArrangedContentFlxed)+}. 
PERM   Application-comments        {REQ  #constraint-name  {"25"}, 

PERM  #extemal-data  {ANY_VALUE}} 


7.4.3.28  CompositeArtwork 

;ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ   Generator-for-subordinates  {$CompositeArtworkGFS}. 

REQ   Position  {REQ  #variable-position  { 

PERM  #oftset  {ANY_VALUE}, 
PERM  #separation  {ANY_VALUE}. 
PERM  #alignment  {ANY_VALUE}, 
PERM  #fill-order  {'normal-order'}}}. 

REQ   Dimensions       {REQ  #horizontal-dirnension 

{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #rule-b  {ANY_VALUE}}, 
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REQ  #vertical-climension 

{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #rule-b  {ANY_VALUE}}}. 

CASE  SUPERIOR  ({CompositeFixtureVariable  |  CompositeFixtureFixed} 

(Layout-path))  OF  { 

{■270-clegrees*}; 

PERM  Layout-path  {'270-clegrees'} 
{'0-degrees'}: 

REQ  Layout-path       {'O-degrees  j 

{'180-degrees'}: 

REQ  Layout-path  {'180-degrees'} 

}}. 

REQ    Application-comments         {REQ  #constraint-name  {"26"}, 

PERM  #extemal-data  {ANY_VALUE}} 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class  {OBJECT_CLASS_ID_OF(CompositeArtwork)} 

$FPDA: 

REQ   Object-class  {OBJECT_CLASS_ID_OF(CompositeArtwork)} 

}. 

REQ  Subordinates  {SUB_ID_OF(BasicFixture)+}, 
PERM  Imaging-order  {SUB_ID_OF(BasicFixture)+}, 
PERM   Application-comments        {REQ  #constraint-name  {"26"}, 

PERM  #external-data  {ANY_VALUE}} 

} 


7.4.3.29  BasicHeader 


:ANY-FRAME-FIXED  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Logical-source 

}. 

PERM  Layout-path 

REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object-class 

}. 

REQ  Subordinates 

PERM  Application-comments 


} 


{OBJECT_CLASS_ID_OF(CommonContent)} 

{'270-degrees'  ~  H/F  layout  A1  - 
I'leo-degrees'  -  H/F  layout  B1  -}, 
{REQ  #constraint-name  {"27"}, 
PERM  #extemal-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF(BasicHeader)} 

{OBJECT_CLASSJD_OF(BasicHeader)} 

{SUB_ID_OF(SpecificBlock)+}. 
{REQ  #constraint-name  {"27"}, 
PERM  #external-data  {ANY_VALUE}} 
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7.4.3.30  BasicFooter 


;ANY-FRAME-FIXED  { 
GENERIC; 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Logical-source 

}. 

PERM  Layout-path 

REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object-class 

}. 

REQ  Subordinates 

PERM  Application-comments 


} 


{OBJECT_CLASS_ID_OF(CommonContent)} 

{•270-degrees'  -  H/F  layout  A1  -- 
ri80-degrees'  -  H/F  layout  B1  -}, 
{REQ  #constraint-name  {"33"}. 
PERM  #external-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF(BasicFooter)} 

{OBJECT_CLASS_ID_OF(BasicFooter)} 

{SUB_ID_OF(SpecificBlock)-H}. 
{REQ  #constraint-name  {"33"}. 
PERM  #extemal-data  {ANY_VALUE}} 


7.4.3.31  BasicBody 

:ANY-FRAME-FIXED  { 
GENERIC: 

PERM  Layout-path 


REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object-class 

}. 

REQ  Subordinates 

PERM  Application-comments 


{'270-degrees'  -  body  layout  A  - 
fO-degrees'   -  body  layout  B  - 
I'leO-degrees'  -  body  layout  C  -}, 
{REQ  #constraint-name  {"28"}. 
PERM  #extemal-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF(BasicBody)} 

{OBJECT_CLASS_ID_OF(BasicBody)} 

{SUBJD_OF(SpecrticBlock)-h}. 
{REQ  #constraint-name  {"28"}. 
PERM  #extemal-data  {ANY_VALUE}} 


7.4.3.32  GenehcBlock 


GENERIC: 

REQ  Object-type 
REQ  Object-class-identifier 
REQ  Content-architecture-class 
PERM  Content-generator 


{'block'}, 
{ANY_VALUE}, 

{$FC  I  $FPC  I  $FPR  I  $FPG  }. 
{$GENERICBLOCKREF}. 
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PERM  Content-portions 


PERM  Presentation-style 


PERM  Resource 

REQ  Application-comments 

SPECIFIC: 

REQ    Object -type 
REQ  Object-identifier 
CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object-class 


{CONTENTJD_OF(Character-content-portion)+ 

I  CONTENT_ID_OF(Raster-graphics-content-portion) 

I  CONTENT__ID_OF(Geometric-graphics-content-portion) 

{STYLEJD_0F(PStyle1) 

I  STYLEJD_0F(PStyle2) 

I  STYLE_ID_0F(PStyle3)}, 

{ANY_VALUE}, 

{REQ  #constraint-name  {"29"}, 
PERM  #external-data  {ANY_VALUE}} 

{'block'}. 
{ANY_VALUE}, 


{OBJECT_CLASSJD_OF(GenericBlock)} 
{OBJECT_CLASS_ID_OF(GenericBlock)} 


}. 

PERM 


Presentation-style 


PERM 
CASE 


Content-architecture-class 
GenericBlock  (Object-class)  OF 


{STYLEJD_0F(PStyle1) 
I  STYLEJD_0F(PStyle2) 
I  STYLE_ID_0F(PStyle3)}, 
{$FC  I  $FPC  I  $FPR  I  $FPG 


VOID: 


}. 


REQ   Content-portions  {CONTENT_ID_OF(Character-content-portion)+ 
|CONTENT_ID_OF(  Raster-graphics-content-portion) 
|CONTENT_ID_OF(Geometric-graphics-content-portion)} 


PERM  Presentation-attributes 
PERM  #character-attributes 


PERM 

#alignment 

{ANY  VALUE}. 

PERM 

#character-fonts 

{ANY  VALUE}. 

PERM 

#character-path 

{ANY  VALUE}, 

PERM 

#character-spacing 

{ANY  VALUE}, 

PERM 

#character-orientation 

{ANY  VALUE}, 

PERM 

#code-extension-announcers 

{$CDEXTEN}. 

PERM 

#first-line-offset 

{ANY  VALUE}. 

PERM 

#graphic-character-sets 

{$PERMIT-GRCHAR}. 

PERM 

#graphic-character-subrepertoire  {ANY_VALUE}, 

PERM 

#graphic-rendition 

{$GRAPHICRENDITIONS}, 

PERM 

#itemisation 

{ANY_VALUE}, 

PERM 

#kerning-oftset 

{ANY_VALUE}, 

PERM 

#line-layout-table 

{ANY  VALUE}. 

PERM 

#line-progression 

{ANY  VALUE}, 

PERM 

#line-spacing 

{ANY  VALUE}, 

PERM 

#pairwise-kerning 

{ANY_VALUE}, 

PERM 

#formatting-indicator 

{ANY_VALUE}, 

PERM 

#initial-otfset 

{ANY_VALUE} 

} 

}. 

PERM 


Application-comments 


SPECIFIC_AND_GENERIC: 
PERM  Position 


{REQ  #constraint-name  {"29"}, 
PERM  #external-data{ANY_VALUE}} 

{REQ  #fixed-position 

{REQ  #horizontal-position  {ANY_VALUE}, 
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PERM  Dimensions 


PERM  Transparency 
PERM  Colour 
PERM  Border 

PERM  User-readable -comments 
PERM  User-visible-name 


REQ  #vertical-position  {ANY_VALUE}}}. 
{REQ  #horizontal-dimension 

{REQ  #tixed-dimension  {ANY_VALUE}}, 
REQ  #vertical-dimension 

{REQ  #tixed-dimension  {ANY_VALUE}}}. 
{ANY_VALUE}, 
{ANY_VALUE}. 
{ANY_VALUE}. 
{ANY_STRING}. 
{ANY_STRING} 


7.4.3.33  SpecificBlock 


{ 

SPECIFIC; 

REQ  Object-type 
REQ  Object-identifier 
REQ  Content-portions 


PERM  Position 


PERM  Dimensions 


PERM  Presentation-style 


PERM  Content-architecture-class 
PERM  Presentation-attributes  { 
PERM  #character-attributes  { 

PERM  #alignment 

PERM  #character-fonts 

PERM  #character-path 

PERM  #character-spacing 

PERM  #character-orientation 

PERM  #code-extension-announcers 

PERM  #first-line-offset 

PERM  #graphic-character-sets 

PERM  #graph 

PERM  #graph 

PERM  #5temisation 

PERM  #kerning-offset 

PERM  #line -layout-table 

PERM  #line-progression 

PERM  #line-spacing 

PERM  #pa!rwise-kerning 

PERM  #formatting-indicator 

PERM  #initial-offset 


{'block'}. 
{ANY_VALUE}, 

{CONTENT_ID_OF(Character-content-portion)+ 
|CONTENT_ID_OF(Raster-graphics-content-portion) 
|CONTENT_ID_OF(Geometric-graphics-content-portion)}. 
{REQ  #1ixed-position 

{REQ  #horizontal-position  {ANY_VALUE). 
REQ  #vertical-position  {ANY_VALUE}}}. 
{REQ  ^horizontal-dimension 

{REQ  #tixed-dimension  {ANY_VALUE}}, 
REQ  #vertical-dimension 

{REQ  #1ixed-dimension  {ANY_VALUE}}}. 
{STYLE_ID_OF(PStyle1) 
I  STYLE_ID_0F(PStyle2) 
I  STYLE_ID_0F(PStyle3) 
I  SmE_ID_0F(PStyle4)}, 
{$FC  I  $FPC  I  $FPR  I  $FPG}, 


{ANY_VALUE}, 
{ANY_VALUE}, 
{ANY_VALUE}, 
{ANY_VALUE}, 
{ANY_VALUE}. 
{$CDEXTEN}, 
{ANY_VALUE}. 
{$PERMIT-GRCHAR  }. 
c-character-subrepertoire  {ANYVALUE}, 
c-rendition  {$GRAPHICRENDITIONS}. 

{ANY_VALUE}, 
{ANY_VALUE}. 
{ANY_VALUE}, 
{ANY_VALUE}, 
{ANY_VALUE}, 
{ANY_VALUE}, 
{ANY_VALUE}, 
{ANY_VALUE} 
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PERM 

Tran^narpnrv 

(ANY  VALUE) 

PERM 

Colour 

(ANY  VALUE) 

PERM 

Border 

{anyIvalue  }. 

PERM 

User-readable -comments 

{ANY  STRING}, 

PERM 

User-visible-name 

{ANY_STRING}, 

PERM 

Application-comments 

{REQ  #constraint-name  {"30"}, 
PERM  #external-data  {ANY_VALUE}} 

7.4.3.34  FotmArea 


:ANY-FRAME-VARIABLE  { 
GENERIC; 

CASE  $DAC  OF  { 
$PDA-FPDA: 
REQ 
REQ  Position 


REQ  Dimensions 


PERM  Layout-path 


Generator-for-subordinates        {$FormAreaGFS}} , 
{REQ  #variable-position  { 

PERM  #offset  {ANY_VALUE}, 
PERM  #separation  {ANY_VALUE}, 
PERM  #alignment  {ANY_VALUE}. 
PERM  #fill-order  {'normal-order'}}}, 
{REQ  #horizontal-dimension 

{REQ  #tixed-dimension  {ANY_VALUE}}, 
REQ  #vertical-dimension 

{REQ  #tixed-dimension  {ANY_VALUE}}}, 
{'270-degrees'}, 


REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object-class 

}. 

REQ  Subordinates 


PERM  Position 
PERM  Dimensions 


PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Transparency 
PERM  Colour 
PERM  Border 

} 


{REQ  #constraint-name  {"31"}, 
PERM  #extemal-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF(FormArea)} 
{OBJECT_CLASSJD_OF(FormArea)} 

{SUB_ID_OF(ArrangedContentFixed)-t-, 

SUBJD_OF(FormEntryArea)-i-, 

SUBJD_OF(EntryGroupArea)+}, 
{ANY_VALUE}, 
{REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}, 

REQ  #vertical-dimension 

{REQ  #tixed-dimension  {ANY_VALUE}}}. 
{REQ  #constraint-name  {"31"}, 

PERM  #external-data  {ANY_ VALUE}} 

{ANY_VALUE}, 
{ANY_VALUE}, 
{ANY_VALUE} 
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7.4.3.35  EntryGroupArea 


;ANY-FRAME-FIXED  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ   Generator-for-subordinates  {$ErrtryGroupAreaGFS} 


REQ  Position 


REQ  Dimensions 


PERM  Layout-path 

REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object-Class 

}. 

REQ  Subordinates 


PERM  Position 
PERM  Dimensions 


PERM  Imaging-order 

PERM  Application-comments 

SPECIFIC_AND_GENERIC: 

PERM  Transparency 

PERM  Colour 

PERM  Border 

} 


{REQ  #fixed-position 

{REQ  #horizontal-position  {ANY_VALUE}. 

REQ  #vertical-position  {ANY_VALUE}}}. 
{REQ  #horizontai-dimension 

{REQ  #fixedKjimension  {ANY_VALUE}}. 
REQ  #vertical-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}}. 
{•270-degrees'}, 

{REQ  #constraint-name  {"35"}, 
PERM  #extemal-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF{EntryGroupArea)} 

{OBJECT_CLASS_ID_OF(EntryGroupArea)} 

{SUBJD_OF(ArrangedContentFixed)+, 
SUB_ID_OF(FormEntryArea)+, 
SUB_ID_OF(EntryGroupArea)+}, 
{ANY_VALUE}, 
{REQ  #horizontal-dimension 

{REQ  #tixed-dimension  {ANY_VALUE}}, 
REQ  #vertical-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}}. 
{ANY_VALUE}. 

{REQ  #constraint-name  {"35"}, 
PERM  #extemal-data  {ANY_VALUE}} 


{ANY_VALUE}, 
{ANY_VALUE}. 
{ANY_VALUE} 


7.4.3.36  TableArea 

:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ   Generator-for-subordinates  {$TableAreaGFS} 

}. 

REQ    Position  {REQ  #variable-position  { 

PERM  #offset  {ANY_VALUE}, 
PERM  #separation  {ANY_VALUE}. 
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REQ  Dimensions 


PERM  Layout-path 

REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object-class 

}. 

REQ  Subordinates 


PERM  Position 
PERM  Dimensions 


PERM  Application-comments 

SPECIFIC.  AND_GENERIC : 
PERM  Transparency 
PERM  Colour 
PERM  Border 


PERM  #alignment  {ANY_VALUE}. 

PERM  #fill-order  {  normal-order  }}}, 
{REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}, 
REQ  #vertical-dimension 

{REQ  #rule-b  {ANY_VALUE} 

|REQ  #fixed-dimension  {ANY_VALUE}}}, 
{'270-degrees'}, 

{REQ  #constraint-name  {"36"}, 
PERM  #extemai-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF(TableArea)} 
{OBJECT_CLASSJD_OF(TableArea)} 

{SUB_ID_OF(RowArea)+, 

SUBJD_OF(TableLabel)+, 

SUBJD_OF(TableHeader)}, 
{ANY_VALUE}, 
{REQ  #horizontal-dimension 

{REQ  #tixed-dimension  {ANY_VALUE}}, 

REQ  #vertical-dimension 

{REQ  #tixed-dimension  {ANY_VALUE}}}, 
(REQ  #constraint-name  {"36"}. 

PERM  #extemal-data  {ANY_VALUE}} 


{ANY_VALUE}, 
{ANY_VALUE}, 
{ANY_VALUE} 


7.4.3.37  TableHeader 


:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ   Generator-for-subordinates  {$TableHeaderGFS} 


REQ  Position 


REQ  Dimensions 


PERM  Layout-path 

REQ  Application-comments 


{REQ  #variable-position  { 

PERM  #offset  {ANY_VALUE}, 
PERM  #separation  {ANY_VALUE}, 
PERM  #alignment  {ANY_VALUE}, 
PERM  #fill-order  {  normal-order  }}}, 

{REQ  #horizontal-dimension 

{REQ  #tixed-dimension  {ANY_VALUE}}, 

REQ  #vertical-dimension 

{REQ  #rule-b  {ANY_VALUE} 

|REQ  #tixed-dimension  {ANY_VALUE}}}. 

{•270-degrees'}, 

{REQ  #constraint-name  {"34"}, 
PERM  #extemal-data  {ANY_VALUE}} 
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SPECIFIC. 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object-class 

}. 

REQ  Subordinates 
PERM  Position 
PERM  Dimensions 


PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Transparency 
PERM  Colour 
PERM  Border 

} 


{OBJECT_CLASS_ID_OF(TableHeader)} 

{OBJECT_CLASS_l  D_OF(TableHeader)} 

{SUB_ID_OF(SourcedContentFixed)+}, 

{ANY_VALUE}. 

{REG  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}. 
REQ  #vertical-dimension 

{REQ  #tixed-dimension  {ANY_VALUE})}. 
{REQ  #constraint-name  {"34"}. 
PERM  #extemal-data  {ANY_VALUE}} 

{ANY_VALUE}. 
{ANY_VALUE}. 
{ANY_VALUE} 


7.4.3.38  TableLabel 

:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA; 

REQ   Generator-for-subordinates  {$TableLabelGFS} 


}. 

REQ  Position 


REQ  Dimensions 


PERM  Layout-path 

REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-Class 

$FPDA: 

REQ  Object-class 

}. 

REQ  Subordinates 

PERM  Position 
PERM  Dimensions 


{REQ  #variable-position  { 

PERM  #offset  {ANY_VALUE}, 

PERM  #separation  {ANY_VALUE}. 

PERM  #alignment  {ANY_VALUE}. 

PERM  #fill-order  {'normal-order'}}}, 
{REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}. 
REQ  #verlical-dimension 

{REQ  #rule-b  {ANY_VALUE} 

|REQ  #1ixed-dimension  {ANY_VALUE}}}. 
{'270-degrees'}. 

{REQ  #constraint-name  {"37"}, 
PERM  #extemal-data  {ANY_VALUE}} 


{OBJECT_CLASSJD_OF(TableLabel)} 

{OBJECT_CLASS_ID_OF(TableLabel)} 

{SUB_ID_OF(TableLabelContent)+. 
SUB_ID_OF(CompositeTableLabel)}, 
{ANY_VALUE}, 
{REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}. 
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PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Transparency 
PERM  Colour 
PERM  Border 

} 


REQ  #vertical-dimension 

{REQ  #1ixed-dimension  {ANY_VALUE}}}. 
{REQ  #constraint-name  {"37"}, 
PERM  #extemal-data  {ANY_VALUE}} 

{ANY_VALUE}. 
{ANY_VALUE}. 
{ANY_VALUE} 


7.4.3.39  CompositeTableLabel 


:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ   Generator-for-subordinates  {$CompositeTableLabelGFS} 


REQ  Position 


REQ  Dimensions 


PERM  Layout-path 

REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 


$FPDA: 


REQ  Object-class 


REQ  Subordinates 
PERM  Position 
PERM  Dimensions 


PERM  Imaging-order 
PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Transparency 
PERM  Colour 
PERM  Border 


{REQ  #fixed-position  { 

REQ  #horizontal-position  { AN Y_ VALUE}. 
REQ  #vertical-position  {ANY_VALUE}}}, 

{REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}. 

REQ  #vertical-dimension 

{REQ  #rule-b  {ANY_VALUE} 

|REQ  #fixed-dimension  {ANY_VALUE} 

|REQ  #maximum-size  {'applies'}}}. 

{•270-degrees'}, 

{REQ  #constraint-name  {"38"}. 
PERM  #extemal-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF 

(CompositeTableLabel)} 

{OBJECT_CLASS_ID_OF 

(CompositeTableLabel)} 

{SUB_ID_OF(LabelComponent)+}, 

{ANY_VALUE}. 

{REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}. 
REQ  #vertical-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}}, 
{ANY_VALUE}. 

{REQ  #constraint-name  {"38"}, 
PERM  #external-data  {ANY_VALUE}} 


} 


{ANY_VALUE}. 
{ANY_VALUE}, 
{ANY_VALUE} 
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7.4.3.40  LabelComponent 


:ANY-FRAME-VARIABLE  { 
GENERIC; 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Generator-for-subordinates 


{$LabelComponentGFS} 


REQ  Position 


REQ  Dimensions 


PERM  Layout-path 

REQ  Application-comments 

SPECIFIC: 

CASE$DACOF{  .j., 
$FDA: 

PERM  Object-Class 

$FPDA: 

REQ  Object-class 

}• 

REQ  Subordinates 
PERM  Position 
PERM  Dimensions 


PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Transparency 
PERM  Colour 
PERM  Border 

}  . 


(REQ  #variable-position  { 

PERM  #oftset  {ANY_VALUE}, 
PERM  #separation  {ANY_VALUE}, 
PERM  #alignment  {ANY_VALUE}. 
PERM  #till-order  {'normal-order'}}}. 

{REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_ VALUE}}, 

REQ  #vertical-dimension 

{REQ  #rule-b  {ANY_VALUE} 

|REQ  #tixed-dimension  {ANY_VALUE} 

|REQ  #maximum-size  {'applies'}}}. 

('270-degrees'}, 

{REQ  #constraint-name  {"39"}, 
PERM  #external-data  {ANY_ VALUE}} 


{OBJECT_CLASS_ID_OF(LabelComponent)} 

{OBJECT_CLASS_ID_OF(LabelComponent)} 

{SUB_ID_OF(TableLabelContent)-t-}, 

{ANY_VALUE}, 

{REQ  #horizontal-dimension 

{REQ  #tixed-dimension  {ANY_VALUE}}, 
REQ  #verlical-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}}. 
{REQ  #constraint-name  {"39"}, 
PERM  #external-data  {ANY_VALUE}} 


{ANY_VALUE}. 
{ANY_VALUE}, 
{ANY_VALUE} 


7.4.3.41  RowArea 


;ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ   Generator-for-subordinates  {$RowAreaGFS} 

}■ 

REQ   Position  {REQ  #variable-position  { 

PERM#offset  {ANY_VALUE}, 
PERM  #separation  {ANY_VALUE}, 
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REQ  Dimensions 


PERM  Layout-path 

REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object-class 

}. 

REQ  Subordinates 

PERM  Position 
PERM  Dimensions 


PERM  Application-comments 

SPECIFIC.  AND_GENERIC: 
PERM  Transparency 
PERM  Colour 
PERM  Border 

} 


PERM  #alignment  {ANY_VALUE}, 
PERM  #fill-order  {'normal-order'}}}. 

{REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}, 

REQ  #vertical-dimension 

{REQ  #mle-b  {ANY_VALUE} 

|REQ  #fixed-dimension  {ANY_VALUE}}}, 

{'270-degrees'}, 

{REQ  #constraint-name  {"40"}, 
PERM  #externai-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF(RowArea)} 

{OBJECT_CLASS_ID_OF(RowArea)} 

{SUBJD_OF(Cell)+, 
SUBJD_OF(SubRowGroup)}, 
{ANY_VALUE}, 
{REQ  #hori2ontai-dimension 

{REQ  #tixed-dimenslon  {ANY_VALUE}}. 
REQ  #vertical-dimension 

{REQ  #1ixed-dimension  {ANY_VALUE}}}, 
{REQ  #constraint-name  {"40"}, 
PERM  #externai-data  {ANY_VALUE}} 


{ANY_VALUE}, 
{ANY_VALUE}. 
{ANY_VALUE} 


7.4.3.42  Cell 


:ANY-FRAME-VARIABLE  { 
GENERIC: 

REQ  Position 


REQ  Dimensions 


{REQ  #tixed-position  { 

REQ  #horizontal-position  {ANY_ VALUE}, 
REQ  #vertical-position  {ANY_VALUE}}}. 

{REQ  #tiorizontal-dimension 

{REQ  #tixed-dimension  {ANY_VALUE}}, 

REQ  #vertical-dimension 

{REQ  #rule-b  {ANY_VALUE} 

|REQ  #1ixed-dimension  {ANY_VALUE} 

|REQ  #maximum-size  {'applies'}}}, 


PERM  Layout-path  {'ayo-degrees'}, 
REQ   Permitted-categories  {ANY_STRING...}, 

-  category  name  for  tables  should  be  specified  - 
REQ   Application-comments  {REQ  #constraint-name  {"41"}, 

PERM  #external-data  {ANY_VALUE}} 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 
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$FPDA: 


PERM  Object-class  {OBJECT_CLASS_ID_OF(Cell)} 
REQ   Object-class  {OBJECT_CLASS_ID_OF(Cell)) 


REQ  Subordinates 
PERM  Position 
PERM  Dimensions 


PERM  Imaging-order 

PERM  Application-comments 

SPECIFIC,  AND_GENERIC: 

PERM  Transparency 

PERM  Colour 

PERM  Border 

} 


{SUB_ID_OF(SpecificBlock)}. 

{ANY_VALUE}. 

{REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}. 
REQ  #vertical-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}}. 
{ANY_VALUE}. 

{REQ  #constraint-name  {"41"}. 
PERM  #extemal-data  {ANY_VALUE}} 

{ANY_VALUE}, 
{ANY_VALUE}. 
{ANY_VALUE} 


7.4.3.43  SubRowGroup 

:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ   Generator-for-subordinates  {SSubRowGroupGFS) 

}. 

REQ   Position  {REQ  #fixed-position  { 

REQ  #horizontal-position  {ANY_ VALUE}. 
REQ  #vertical-position  {ANY_VALUE}}}. 
{REQ  #horlzontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}. 
REQ  #vertical-dimension 

{REQ  #mle-b  {ANY_VALUE} 
I  REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {  applies'}}}. 
{•270-degrees'}. 

{REQ  #constraint-name  {"42"}. 
PERM  #extemal-data  {ANY_VALUE}} 


REQ  Dimensions 


PERM  Layout-path 
REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object-class 

}. 

REQ  Subordinates 
PERM  Position 
PERM  Dimensions 


PERM  Application-comments 


{OBJECT_CLASS_ID_OF(SubRowGroup)} 

{OBJECT_CLASS_ID_OF(SubRowGroup)} 

{SUBJD_OF(SubRow)-h}. 

{ANY_VALUE}. 

{REQ  #hori2ontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}. 
REQ  #vertical-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}}. 
{REQ  #constraint-name  {"42"}. 
PERM  #external-data  {ANY_VALUE}} 
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SPECIFIC_AND_GENERIC: 

PERM  Transparency  {ANY_VALUE}. 

PERM  Colour  {ANY_VALUE}. 

PERM  Border  {ANY_VALUE} 

} 


7.4.3.44  SubRow 


:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Generator-for-subordinates  {$SubRowGFS} 


REQ  Position 


REQ  Dimensions 


PERM  Layout-path 

REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object -class 

}. 

REQ  Subordinates 
PERM  Position 
PERM  Dimensions 


PERM  Application-comments 

SPECIFIC.  AND_GENERIC: 
PERM  Transparency 
PERM  Colour 
PERM  Boixjer 

) 


{REQ  #variable-position  { 

PERM  #offset  {ANY_VALUE}. 
PERM  #separation  {ANY_VALUE}, 
PERM  #alignment  {ANY_VALUE}. 
PERM  #f ill-order  {'normal-order'}}}. 

{REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}, 

REQ  #vertical-dimension 

{REQ  #rule-b  {ANY_VALUE} 

|REQ  #fixed-dimension  {ANY_VALUE} 

|REQ  #maximum-si2e  {'applies'}}}. 

{'270-degrees'}, 

{REQ  #constraint-name  {"43"}, 
PERM  #extemal-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF(SubRow)} 

{OBJECT_CLASS_ID_OF(SubRow)} 

{SUB_ID_OF(Cell)+}. 

{ANY_VALUE}, 

{REQ  #horizontal-dimension 

{REQ  #fixed-dimen5ion  {ANY_VALUE}}, 
REQ  #vertical-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}}. 
{REQ  #constraint-name  {"43"}, 
PERM  #extemal-data  {ANY_VALUE}} 


{ANY_VALUE}. 
{ANY_VALUE}, 
{ANY_VALUE} 


7.4.3.45  TableLabelContent 


:ANY-FRAME- VARIABLE  { 
GENERIC: 
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CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Logical -source 

REQ  Position 


REQ  Dimensions 


}. 


PERM  Layout-path 


REQ  Application-comnfients 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 


$FPDA; 


REQ  Object-class 


REQ  Subordinates 

PERM  Application-comments 


{OBJECT_CLASS_ID_OF(CommonContent)}. 
{REQ  #fixed-position 

{REQ  #horizontal-position  {ANY_VALUE}. 
REQ  #venical-position  {ANY_VALUE}}}, 
{REQ  #horizontal-dimension 

{REQ  #1ixed-dimension  {ANY_VALUE}}. 
REQ  #vertical-dimension 

{REQ  #fixed-dimension  {ANY_VALUE} 

|REQ  #maximum-size  {'applies'}}}, 

{'270-degrees'} 

{REQ  #constraint-name  {"44"}. 
PERM  #external-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF 

(TableLabelContent)} 

{OBJECT_CLASS_ID_OF 

(TableLabelContent)} 

{SUBJD_OF(SpecificBlock)+}. 
{REQ  #constraint-name  {"44"}, 
PERM  #external-data  {ANY_ VALUE}} 


7.4.3.46  FormEntryArea 

:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Position 


REQ  Dimensions 


PERM  Layout-path 


REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object-class 

}. 

REQ  Subordinates 


{REQ  #fixed-position 

{REQ  #horizontal-position  {ANY_VALUE}, 
REQ  #vertical-position  {ANY_VALUE}}}. 
{REQ  #horizontal-dimension 

{REQ  #tixed-dimension  {ANY_VALUE}}. 
REQ  #vertical-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}}. 
{'270-degrees*} 

{REQ  #constraint-name  {"45"}. 
PERM  #external-data  {ANY_VALUE}} 


{OBJECT_CLASSJD_OF(FormEntryArea)} 
{OBJECT_CLASS_ID_OF(FormEntryArea)} 
{SUB_ID_OF(SpecificBlock)}. 
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PERM  Application-comments  {REQ  #constraint-name  ("45"}, 

PERM  #extemal-data  {ANY_VALUE}} 

SPECIFIC.  AND_GENERIC : 

PERM  Pemriitted-categories  {ANY_STRING.  .} 

} 


7.5  Layout  style  constituent  constraints 


7.5.1  Macro  definitions 


DEFINE(SameLayoutObject," 

REQ  {REQ  #loglcal-object  {<object-id-expr>;:=PREC-OBJ(CURR-OBJ);} 

I  REQ  #logical-object  {'null'}}, 
PERM  #layout-object   {'page'  --  to  layout  object  type  -- 

I  ANY_STRING  --  to  layout  category  -- 

i  OBJECT_CLASS_ID_OF{ColumnFixed) 
I  OBJECT_CLASS_ID_OF(ColumnVariable) 
I  OBJECT_CLASS_ID_OF(CompositeColumnFixed) 
I  OBJECT_CLASSJD_OF(CompositeColumnVariable)} 


7.5.2  Factor  constraints 

FACTOR  ANY-LAYOUT-STYLE 


{ 

REQ  Layout-style-identitier 

PERM  User-visible-name 

PERM  User-readable-comments 
} 


{ANY_VALUE}. 

{ANY_STRING}. 

{ANY_STRING} 


7.5.3  Constituent  constraints 


7.5.3.1  LStylel 

:ANY-LAYOUT-STYLE  { 

--  Ttiis  layout  style  is  only  applicable  to  composite  logical  constituent  constraints  including  the  Passage, 
NumberedSegment,  Title,  Caption,  Paragraph,  Phrase,  Footnote,  Figure.  Reference.  Description, 
NumberedList,  UnNumberedList,  DefinitionList,  Listltem,  ListTerm  - 

CASE  $GLAS  0F{ 
$COMPLETE: 

PERM  Indivisibility 

PERM  Layout-object-class 

PERM       New-layout -object 

PERM  Same-layout-object 

PERM  Synchronization 
VOID: 

PERM  Indivisibility 


{ANY_VALUE}, 
{ANY_VALUE}, 
{ANY_VALUE}, 
{$SameLayoutObject} , 
{ANY_VALUE} 

{ANY_STRING  -to  layout  category- 
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PERM  New-layout-object 


PERM  Same-layout-object 


}} 


PERM  Synchronization 


I'page"     -to  layout  object  type- 
Inull}, 

{ANY_STRING  -to  layout  category- 
I'page'     -to  layout  object  type- 
rnuir}. 

REQ  {REQ  #logical-object 

{<object-id-expr>::=PREC-OBJ(CURR-OBJ);} 
I  REQ  #logical-object  {'null'}}. 
PERM  #layout-object 

{ANY_STRING  -to  layout  category - 
I'page'     -to  layout  object  type-} 

}. 

{ANY.VALUE} 


7.5.3.2  LStyle2 

:ANY-LAYOUT-STYLE  { 

-  This  layout  style  is  only  applicable  to  the  constituent  constraints  Number  and  BodyText  - 


CASE  $GLAS  0F{ 
$COMPLETE: 

PERM 

PERM 

PERM 

PERM 

PERM 

PERM 

PERM 

PERM 

PERM 

PERM 
VOID: 

PERM 

PERM 

PERM 


PERM 
PERM 


PERM 
PERM 


Block-alignment 
Concatenation 
Indivisibility 
Layout-category 
Layout-object-class 
New-layout-object 
Offset 

Same-layout-object 
Separation 
Synchronization 


Block-alignment 
Concatenation 
Indivisibility 


Layout-category 
New-layout-object 


Offset 

Same-layout-object 


PERM 
PERM 


Separation 
Synchronization 


{ANY_VALUE}. 

{ANY_VALUE). 

{ANY_VALUE}. 

{ANY_VALUE}, 

{ANY_VALUE}. 

{ANY_VALUE}. 

{ANY_VALUE}. 

{SSameLayoutObject}, 

{ANY_VALUE}, 

{ANY_VALUE} 

{ANY_VALUE}, 
{ANY_VALUE}, 

{ANY_STRING  -to  layout  category- 
I'page*     -to  layout  object  type- 
I'null'}. 

{ANY_VALUE}, 

{ANY_STRING  -to  layout  category - 
I'page'     -to  layout  object  type- 
I'nuir}. 

{ANY_VALUE}. 
REQ  {REQ  #logical-object 

{<object-id-expr>::=PREC-OBJ(CURR-OBJ);} 
I  REQ  #logical-object  {'null'}}, 
PERM  #layout-object 

{ANY_STRING  -to  layout  category- 
I'page'     -to  layout  object  type-} 

}. 

{ANY_VALUE}. 
{ANY_VALUE} 
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}} 


7.5.3.3  LStyle3 

:ANY-LAYOUT-STYLE{ 

--  This  layout  style  is  used  only  for  the  constituent  constraints  CommonText,  PageNumber, 
TableNumber.  Currentlnstance,  CommonNumber  and  CommonReference  -- 

PERM  Block-alignment  {ANY_VALUE}. 

PERM  Concatenation  {ANY_VALUE}, 

PERM  Offset  {ANY_VALUE}. 

PERM  Separation  {ANY_VALUE} 

} 


7.5.3.4  LStyl94 

--  This  layout  style  is  not  used  -- 


7.5.3.5  LStyle5 


:ANY-LAYOUT-STYLE  { 

--  This  layout  style  is  used  only  for  the  constituent  constraints  BodyRaster  and  BodyGeometric 


CASE  $GLAS  0F{ 
$COMPLETE: 

PERM 

PERM 

PERM 

PERM 

PERM 

PERM 

PERM 

PERM 
VOID: 

PERM 

PERM 

PERM 


Block-alignment 
Layout-category 
Layout-object-class 
New-layout -object 
Offset 

Same-layout-object 
Separation 
Synchronization 


Block-alignment 
Layout-category 
New-layout-object 


PERM  Offset 

PERM  Same-layout-object 


{ANY_VALUE}, 

{ANY_VALUE}, 

{ANY_VALUE}, 

{ANY_VALUE}. 

{ANY_VALUE}, 

{$SameLayoutObject} , 

{ANY_VALUE}, 

{ANY_VALUE} 

{ANY_VALUE}. 
{ANY_VALUE}. 

{ANY_STRING  -to  layout  category- 
I'page"     -to  layout  object  type- 
I'null}, 

{ANY_VALUE}, 
REQ  {REQ  #logical-object 

{<object-id-expr>::=PREC-OBJ(CURR-OBJ);} 
I  REQ  #logical-object  {'null'}}. 
PERM  #layout-object 

{ANY_STRING  -to  layout  category- 
I'page'     -to  layout  object  type-} 


}} 


PERM  Separation 
PERM  Synchronization 


}. 

{ANY_VALUE}, 
{ANY_VALUE} 
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7.5.3.6  LStylee 


:ANY-LAYOUT-STYLE  { 


--  This  layout  style  is  used  only  for  the  constituent  constraint  FootnoteText 


CASE  $GLAS  OF{ 
$COMPLETE: 

PERM 

PERM 

PERM 

REQ 

PERM 

PERM 
VOID: 

PERM 


Indivisibility 
Block-alignment 
Concatenation 
Layout-category 
Offset 
Separation 


Indivisibility 


PERM  Block-alignment 

PERM  Concatenation 

REQ  Layout-category 

PERM  Offset 

PERM  Separation 


{ANY_VALUE}. 

{ANY_VALUE}. 

{ANY_VALUE}. 

{$FOOTNOTECATEGORY}. 

{ANY_VALUE}. 

{ANY_  VALUE} 

{ANY_STRING  -to  layout  category- 
j'page'     -to  layout  object  type- 
Inull}. 

{ANY_VALUE}. 
{ANY_VALUE}. 
{$FOOTNOTECATEGORY} . 
{ANY_VALUE}, 
{ANY_VALUE} 


7.5.3.7  LStyle7 

-  This  layout  style  is  not  used.  - 

7.5.3.8  LStyiea 

:ANY-LAYOUT-STYLE  { 

-  This  layout  style  is  used  only  for  the  constituent  constraints  CommonRaster  and  CommonGeometric 


PERM  Block-alignment  {ANY_VALUE}, 
PERM  Offset  {ANY_VALUE}, 
PERM  Separation  {ANY_VALUE} 


7.5.3.9  LStyleS 
:ANY-LAYOUT-STYLE  { 

~  This  layout  style  is  only  applicable  to  the  constituent  constraint  FootnoteNumtjer 

PERM  Block-alignment  {ANY_VALUE}. 

REQ    Layout-category  {$FOOTNOTECATEGORY}. 
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PERM  Offset 
PERM  Separation 

} 


{ANY_VALUE}. 
{ANY_VALUE} 


7.5.3.10  LStylelO 

:ANY-LAYOUT-STYLE  { 

-  This  layout  style  is  only  applicable  to  the  constituent  constraints  FootnoteReference  and 
ReferencedContent  -- 


CASE  $GLAS  0F{ 
$COMPLETE: 

PERM 

PERM 

PERM 

PERM 

PERM 

PERM 

PERM 
VOID: 

PERM 

PERM 

PERM 


PERM 
PERM 
PERM 


PERM 


Block-alignment 
Concatenation 
Indivisibility 
Layout-category 
Offset 

Same-layout-object 
Separation 


Block-alignment 
Concatenation 
Indivisibility 


Layout-category 
Offset 

Same-layout-object 


}} 


Separation 


{ANY_VALUE}, 

{ANY_VALUE}, 

{ANY_VALUE}. 

{ANY_VALUE}. 

{ANY_VALUE}, 

jSSameLayoutObject} . 

{ANY_VALUE} 

{ANY_VALUE}, 
{ANY_VALUE}. 

{ANY_STRING  -to  layout  category- 
I'page'     -to  layout  object  type- 
I'null'}, 

{ANY_VALUE}, 
{ANY_VALUE}. 
REQ  {REQ  #logical-object 

{<object-id-expr>::=PREC-OBJ(CURR-OBJ);} 
I  REQ  #logical-object  {"null"}}. 
PERM  #layout-object 

{ANY_STRING  -to  layout  category- 
I'page'     -to  layout  object  type-} 

}. 

{ANY_VALUE} 


7.5.3.11  LStylell 

:ANY-LAYOUT-STYLE  { 

-  This  layout  style  is  used  only  for  the  constituent  constraint  FootnoteBody 


CASE  $GLAS  0F{ 

$COMPLETE: 
PERM  Indivisibility 
PERM  Same-layout-object 
PERM  Synchronization 

VOID: 
PERM  Indivisibility 


{ANY_VALUE}. 
{$SameLayoutObject} . 
{ANY_VALUE} 

{ANY_STRING  -to  layout  category- 
I'page'     -to  layout  object  type- 
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PERM  Same-layout-object 


}} 


PERM  Synchronization 


rnull'}. 

REQ  {REQ  #logical-object 

{<object-id-expr>::=PREC-OBJ(CURR-OBJ);} 
I  REQ  #logical-object  {'null'}}, 
PERM  #layout-object 

{ANY_STRING  -to  layout  category- 
I'page'     -to  layout  object  type-} 

}. 

{ANY_VALUE} 


7.5.3.12  LStyle12 

:ANY-LAYOUT-STYLE  { 

-  This  layout  style  is  used  only  for  the  constituent  constraint  Artwork 


CASE  $GLAS  0F{ 
SCOMPLETE: 
PERM  Indivisibility 


PERM 
PERM 


PERM 
VOID: 
PERM 


PERM 


Layout-object-class 
New-layout -object 


Synchronization 
Indivisibility 

New-layout -object 


}} 


PERM  Synchronization 


{ANY_STRING  -  to  layout  category  - 
I'page"  -  to  layout  object  type  -- 

rnull'}, 

{OBJECT_CL  ASS_I  D_OF(CompositeAnwork)} . 

{OBJECT_CLASS_ID_OF(CompositeColumnFixed) 

|OBJECT_CLASS_ID_OF(CompositeColumnVariable) 

-  to  layout  object  class  - 
|ANY_STRING  -  to  layout  category  - 
I'page'  -  to  layout  object  type  - 

rnull'}, 

{ANY_VALUE) 

jANY_STRING  -to  layout  category- 
rpage'     -to  layout  object  type- 
rnull'}, 

iANY_STRING  -to  layout  category - 
I'page'     -to  layout  object  type- 
I'null'}. 

{ANY_VALUE} 


7.5.3.13  LStyleTI 

ANY-LAYOUT-STYLE  { 

-  This  layout  style  is  used  only  for  the  constituent  constraint  Form 


REQ  Layout-object-class 
) 


{OBJECT_CLASS_ID_OF(FormArea)} 
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7.5.3.14  LStyleT2 


:ANY-LAYOUT-STYLE  { 

--  This  layout  style  is  used  only  for  the  constituent  constraint  EntryElement  -- 

--  In  the  case  of  Form,  the  following  attribute  niust  be  specified.  -- 
REQ  Layout-object-class  {OBJECT_CLASS_ID_OF(FormEntryArea)} 

I 

-  In  the  case  of  Table,  both  of  the  following  attributes  must  be  specified.  -- 
REQ  New-layout-object  {OBJECT_CLASS_ID_OF(Cell)  --  to  layout  object  class 

|ANY_STRING  --  to  layout  category  -}. 

REQ  Indivisibility  {OBJECT_CLASS_ID_OF(Cell)  --  to  layout  object  class 

|ANY_STRING  --  to  layout  category  -- 

} 


7.5.3.15  LStyleT3 

:ANY-LAYOUT-STYLE  { 

-  This  layout  style  is  used  only  for  the  constituent  constraint  EntryGroup  - 

REQ  Layout-object-class  {OBJECT_CLASS_ID_OF(EntryGroupArea)} 
} 


7.5.3.16  LStyleT4 

:ANY-LAYOUT-STYLE  { 

"  This  layout  style  is  used  only  for 

REQ  New-layout-object 
PERM  Indivisibility 


PERM  Same-layout-object 
} 


7.5.3.17  LStyleTS 

:ANY-LAYOUT-STYLE  { 
"  This  layout  style  is  used  only  for  the  constituent  constraint  Row  - 

REQ    New-layout-object  {OBJECT_CLASS_ID_OF(RowArea)}. 

PERM  Indivisibility  {OBJECT_CLASS_ID_OF(RowArea) 

-  to  layout  object  class  -- 
|ANY_STRING  -  to  layout  category  - 
I'page'  ~  to  layout  object  type  -- 

I'null} 


a  logical  object  class  of  the  constituent  constraint  Table  -- 

{OBJECT_CLASSJD_OF(TableArea)}. 
{OBJECT_CLASS_ID_OF{TabteArea) 

-  to  layout  object  class  - 
|ANY_STRING  --  to  layout  category  -- 
I'page'  -  to  layout  object  type  - 

I  'null'  }. 

{$SameLayoutObject} 
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} 

7.5.3.18  LStyleTG 

:ANY-LAYOUT-STYLE  { 

--  This  layout  style  is  used  only  for  the  constituent  constraint  TableComponent 


REQ  Layout-object-class 
} 


{OBJECT_CLASS_ID_OF(SubRowGroup)} 


7.5.3.19  LStyleT7 

:ANY-LAYOUT-STYLE  { 

-  This  layout  style  is  used  only  for  the  constituent  constraint  RowComponent 


REQ  New-layout-object 
PERM  Indivisibility 


} 


{OBJECT_CLASS_ID_OF(SubRow)}. 
{OBJECT_CLASS_ID_OF(SubRow) 

-  to  layout  object  class 
{ANY_STRING  -  to  layout  category  - 
Inull} 


7.5.3.20  LStyleTS 

:ANY-LAYOUT-STYLE  { 

--  This  layout  style  is  used  only  for  a  logical  object  of  the  constituent  constraint  Table 


PERM  Indivisibility 


PERM  Same-layout-object 
} 


{OBJECT_CLASS_ID_OF(TableArea) 

-  to  layout  object  class 
|ANY_STRING  -  to  layout  category  - 
I  page*  -  to  layout  object  type  - 

I'nuir}, 

{$SameLayoutObject} 


7.5.3.21  LStyleT9 

:ANY-LAYOUT-STYLE  { 

"  This  layout  style  is  used  only  for  the  constituent  constraints  EntryText.EntryRaster.EntryGeometric. 


PERM  Block-alignment 
PERM  Layout-category 
PERM  Offset 


{ANY_VALUE}. 
{ANY_VALUE}. 
{ANY_VALUE} 
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7.6  Presentation  style  constituent  constraints 


7.6.1  Macro  definitions 


--  No  macro  definitions  are  applicable  to  this  subclause.  -- 


7.6.2  Factor  constraints 

FACTOR  ANY-PRESENTATION-STYLE 


{ 

REQ 

PERM 

PERM 

PERM 

PERM 

PERM 

} 


Presentation-style-identifier 

User-readable-comments 

User-visible-name 

Border 

Colour 

Transparency 


{ANY_VALUE}. 

{ANY_STRING}. 

{ANY_STRING}, 

{ANY_VALUE}, 

{ANY_VALUE}, 

{ANY_VALUE} 


7.6.3  Constituent  constraints 


7.6.3.1  PStylel 

:ANY-PRESENTATION-STYLE  { 

This  style  is  used  for  the  constituent  constraints  BodyText,  Number,  FootnoteNumber, 
FootnoteReference.  FootnoteText,  Entry  Text,  ReferencedContent,  GenericBlock  and 
SpecificBlock.  - 

PERM  Presentation-attributes  { 
PERM  #character-attributes  { 


PERM 

#alignment 

{ANY  VALUE}, 

PERM 

#character-fonts 

{ANY  VALUE}, 

PERM 

#character-orientation 

{ANY  VALUE}, 

PERM 

#character-path 

{ANY_VALUE}. 

PERM 

#character-spacing 

{ANY  VALUE}, 

PERM 

#code-extension-announcers 

{$CDEXTEN}, 

PERM 

#first-line-offset 

{ANY  VALUE}, 

PERM 

#graphic-character-sets 

{$PERMIT-GRCHAR}. 

PERM 

#graphic-character-subrepertoire  {ANY_VALUE}, 

PERM 

#graphic-rendition 

{$GRAPHICRENDITIONS}, 

PERM 

#indentation 

{ANY  VALUE}. 

PERM 

#itemization 

{ANY  VALUE}. 

PERM 

#kerning-offset 

{ANY  VALUE}. 

PERM 

#line-layout-table 

{ANY  VALUE}. 

PERM 

#line-progression 

{ANY  VALUE}, 

PERM 

#line-spacing 

{ANY_VALUE}, 

PERM 

#orphan-size 

{ANY  VALUE}, 

PERM 

#pairwise-kerning 

{ANY  VALUE}, 

PERM 

#proportional-line-spacing 

{ANY  VALUE}. 

PERM 

#widow-size 

{ANY  VALUE}. 
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PERM  #initial-otfset  {ANY_VALUE}. 

PERM  #1ormatting-indicator  {ANY_VALUE} 

} 

}} 


7.6.3.2  PStyle2 

:ANY-PRESENTATION-STYLE  { 

This  style  is  used  for  the  constituent  constraints  BodyGeometric,  CommonGeometrIc, 
EntryGeometric,  GenericBlock  and  SpecificBlock.  -- 

PERM  Presentation-attributes  { 

PERM  #geometric-graphics-attributes  {ANY_VALUE}} 

} 


7.6.3.3  PStyle3 


:ANY-PRESENTATION-STYLE  { 


This  style  is  used  tor  the  constituent  constraints  BodyRaster,  CommonRaster,  EntryRaster, 
GenericBlock  and  SpecificBlock.  -- 

PERM  Presentation-attributes  { 
PERM  #raster-graphics-attributes  { 


PERM 

#pel-path 

{ANY 

VALUE}, 

PERM 

#line-progression 

{ANY_ 

VALUE}, 

PERM 

#pel-spacing 

{ANY 

_VALUE}. 

PERM 

#spacing-ratio 

{ANY_ 

_VALUE}. 

PERM 

#clipping 

{ANY_ 

VALUE}, 

PERM 

#image-dimensions 

{ANY_ 

VALUE} 

} 

}} 


7.6.3.4  PStyle4 

:ANY-PRESENTATION-STYLE  { 

This  style  is  used  for  the  constituent  constraints  CommonText.  PageNumber,  TableNumber, 
CommonReference,  Currentlnstance  and  SpecificBlock.  - 


PERM  Presentation-attributes  { 
PERM  #character-attributes  ( 
PERM  #alignment 
PERM  #character-fonts 
PERM  #character-orientation 
PERM  #character-path 
PERM  #character-spacing 
PERM  #code-extension-announcers 
PERM  #first-line-offset 
PERM  #graphic-character-sets 


{ANY_VALUE}, 

{ANY_VALUE}, 

{ANY_VALUE}, 

{ANY_VALUE}, 

{ANY_VALUE}. 

{$CDEXTEN}. 

{ANY_VALUE}. 

{SPERMIT-GRCHAR}. 


PERM  #graphic-character-subrepertoire  {ANY_VALUE}. 
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rtriM 

#graphic-rendition 

(JpoHArnlOntlNUl  1  lUNo), 

r  tnM 

fFinaenidiion 

/AMV   \/AI  1  IC\ 

{AiN  Y_VALUt), 

DCDkJ 

rtPlM 

fFiiemizaiion 

(AlMY_VALUt), 

rtnM 

wKeming-oiTSGi 

(  AKIV    \/ Al  1  IC1 

(AiNY_VALUt), 

rtnM 

ffiine-iayoui-iaDie 

1  AKIV    V/AI  1  IC\ 

{ArMY_VALUtJ, 

DCDkA 

rtnM 

ffiine-progression 

1  AKIV    \/ Al  1  ICl 

{AlMY_VALUtJ, 

rtnM 

fFiine-spacing 

f  AKIV   \/AI  1  Id 

{AIN  Y_VALUt), 

rcHM 

#pairwise-kerning 

1  AKIV   \/AI  1  ICl 

(AlNY_VALUt), 

PPRM 
r  criM 

Trproponioiidi  iiiic-spdoiiiy 

PERM 

#initial-otfset 

{ANY  VALUE}, 

PERM 

#formatting-inclicator 

{ANY_VALUE} 

} 

}} 


7.7  Content  portion  constituent  constraints 


7.7.1  Macro  definitions 


DEFINE(T6, 

"ASN.1 

{2837  0}") 

DEFINE(T41D. 

"ASN.1 

{2837  1}") 

DEFINE(T42D. 

"ASN.1 

{2  83  7  2}") 

DEFINE(Bitmap. 

"ASN.I 

{2837  3}") 

7.7.2  Factor  constraints 
FACTOR  ANY-CONTENT  { 


CASE  $DAC  OF  { 
$FDA  : 

REQ  Content-identifier-layout  {ANY_VALUE} 


$PDA  : 

REQ  Content-identifier-logical  {ANY_VALUE} 

"  This  attribute  is  specified,  if  the  content  portion  is  associated  with 
a  basic  logical  object  or  a  basic  logical  object  class.  - 
|REQ  Content-identifier-layout  {ANY_VALUE} 

"  This  attribute  is  specified,  if  the  content  portion  is  associated  with 
a  basic  layout  object  class.  ~ 

$FPDA  : 

REQ  Content-identifier-layout  {ANY_VALUE}, 
REQ  Content-identifier-logical  {ANY_VALUE} 

~  Both  attributes  are  specified,  if  the  content  portion  is  associated  with 
a  basic  logical  object  and  a  basic  layout  object.  ~ 
|REQ  Content-identifier-layout  {ANY_VALUE} 

"  This  attribute  is  soecified,  if  the  content  portion  is  associated  with 
a  basic  layout  object  class.  ~ 
|REQ  Content-identifier-logical  {ANY_VALUE} 

~  This  attribute  is  specified,  if  the  content  portion  is  associated  with 
a  basic  logical  object  class.  - 
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}. 

PERM  Alternative-representation  {ANY_STRING} 
} 


7.7.3  Constituent  constraints 


7.7.3.1  Character-content-portion 

:ANY-CONTENT  { 
PERM  Type-of-coding 
PERM  Content-information 
{ 

--  Shared  Control  Functions  - 
#CR 
I  #GCC 
I  #IGS 
I  #LF 
I  #PLD 
I  #PLU 
|#SCS 
|#SGR 
I  #SHS 
I  #SLS 
I  #SRS 
I #STAB 
I  #SUB 
I  #SVS 
|#VPB 
I  #VPR 

-  Layout  Control  Functions  -- 
I  #HPB 
I  #HPR 
I  #JFY 
I #SACS 
1 #SRCS 
I  #SSW 

--  Logical  Control  Functions  -- 
I  #BPH 
I  #NBH 
I  #PTX 

"  Delimiter  Functions  -- 
I  #SOS 
l#ST 


{ASN.1{2  8  3  6  0}}. 
{CHARACTER 


{ANY_VALUE} 
{ANY_VALUE} 


{ANY_VALUE} 
{SGRAPHICRENDITIONS} 
{ANY_VALUE} 
{ANY_VALUE} 

{ANY_VALUE}    . 

{ANY_VALUE} 

{ANY_VALUE} 
(ANY_VALUE} 
{ANY_VALUE} 


{ANY_VALUE} 
{ANY_VALUE} 
{0) 

{ANY_VALUE} 
{ANY_VALUE} 
{ANY_VALUE} 


{ANY_VALUE} 


Space  - 
I  #SP 

Code  extension  control  functions 
I  #LSO 
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#LS1R 

#LS2R 

#LS3R 

#SS2 

#SS3 

#ESC  {$DEG-CORE-G0} 
#ESC  {$DEG-646-G0} 
#ESC  {$DEG-ANY-G1} 
#ESC  {$DEG-ANY-G2} 
#ESC  {$DEG-ANY-G3} 
#ESC  {$DEG-EMPTY-G1} 


7.7.3.2  Raster-graphics-content-portion 


:ANY-CONTENT  { 

PERM  Type-of-coding 

PERM  Coding-attributes 
PERM  #compression 
PERM  #number-of-lines 
REQ  #number-ol-pels-per-line 
}. 

PERM  Content-intormation 
} 


{$T6|$T41  D|$T42D|$Bitmap}. 
{ 

{ANY_VALUE}. 

{>0}. 

{>=0} 

{RASTER} 


7.7.3.3  Geometric-graphics-content-portion 

:ANY-CONTENT  { 

PERM  Type-of-coding  {ASN.1  {2  838  0}}. 

PERM  Content-intormation  {GEOMETRIC} 


8  Interchange  format 

For  conformance  to  tfiis  profile,  the  interchange  format  class  A  shall  be  used  when  applying  ODIF,  and  the 
interchange  format  SDIF  shall  be  used  when  applying  ODL  in  conjunction  with  SDIF. 

NOTE  30  -  Interchange  format  SDIF  applies  to  the  ISP  only. 


8.1  Interchange  format  class  A 


8.1.1  Interchange  format 

The  value  of  the  document  profile  attribute  "Interchange  format"  for  this  interchange  format  is  "if-a".  This 
form  of  ODIF  is  defined  in  (CCITT  Recomendation  T.415  |  ISO  8613-5]. 
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8.1.2  DAP  identifier 


The  value  for  the  document  profile  attribute  "document  application  profile"  for  this  interchange  format  is 
represented  by  the  following  object  identifier. 

ASN.1  {  2  8  4  0  36  0  } 

8.1.3  Encoding  of  application  comments 

The  encoding  of  the  attribute  "application  comments"  is  defined  in  this  encoding  as  an  octet  string  as 
specified  in  [CCITT  Recommendation  T.415  |  ISO  8613-5].  This  document  application  profile  requires  that 
the  encoding  within  that  octet  string  be  in  accordance  with  the  ASN.1  syntax  specified  in  the  following 
module  definition: 

FOD_DAPSpecification 
DEFINITIONS  ::=  BEGIN 
EXPORTS  Appl-Comm-Encoding; 

Appl-Comm- Encoding  ::=    SEQUENCE  { 

constraint-name  [0]  IMPLICIT  PrintableString  OPTIONAL, 

external-data  (1]  IMPLICIT  OCTETSTRING  OPTIONAL  } 

END 


8.1.4  Data  lengths 

The  maximum  length  of  data  values  of  the  type  OCTET  STRING,  as  defined  in  [ISO  8824  |  CCITT 
Recommendation  X.208).  in  data  streams  which  may  be  encoded  in  accordance  with  this  DAP  is  32767 
octets.  II  it  is  required  to  encode  contents  octets  of  greater  length  than  this,  constructed  type  encoding 
shall  be  used.  That  is.  data  values  greater  than  32767  in  length  shall  be  split  into  a  sequence  of  strings 
shorter  than  32767,  each  of  which  is  encoded  using  a  primitive  type. 


8.2  Interchange  format  SDIF 

NOTE  31  -  The  subclause  8.2  applies  to  the  ISP  only. 


8.2.1  Interctiange  format 

The  document  profile  attribute  "interchange  format"  does  not  apply  for  this  interchange  format.  This  form 
of  the  interchange  format  is  defined  in  Annex  E  of  (CCITT  Recommendation  T.415  |  ISO  8613-5].  (CCITT 
Recommendations  T.416.  T.417.  and  T.418  |  ISO  8613-6,  -7  and  -8]  contain  additional  specifications  for 
this  interchange  format. 


8.2.2  DAP  identifier 

The  value  for  the  attribute  "document  application  profile"  for  this  interchange  format  is  represented  by  the 
following  object  identifier. 

ASN.1  {  1  0  11182  0  36  0  } 

NOTE  32  -  There  is  no  requirennent  to  include  a  part  number  arc  within  the  object  identifier  for  the  DAP. 
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8.2.3  Encoding  of  application  comments 


The  encoding  of  the  attribute  "application  comments"  is  defined  in  data  stream  conforming  to  this  profile 
with  this  encoding  with  the  following  DTD  definition: 

<!--  Public  document  type  definition.  Typical  invocation: 

<!DOCTYPE  fodapc  PUBLIC  "ISO/IEC  1 1 182-1  :  1992//DTD 

Application  Comments//EN"  ( "  ]> 


For  example,  a  typical  SUBDOC  for  representing  the  "application  comments"  of  a  Paragraph  then  would 
look  like: 

<!DOCTYPE  fodapc  PUBLIC  "ISO/IEC  11182-1  : 1992//DTD  Application  Comments//EN"> 
<fodapc  consname=6> 

If  the  optionality  of  the  attribute  "fodapc"  is  specified  in  an  earlier  portion  of  the  DTD,  the  invocation  may 
be  minimized  further  because  the  tag  is  not  needed  when  "application  comments"  are  not  included  as  is 
the  case  here. 

The  content  of  external  data  appearing  inline  is  restricted  to  parsable  data.  Referenced  extemal  data  need 
not  be  parsable. 


-> 


<!ELEMENT  fodapc 
<!ATTLIST  fodapc 
< ELEMENT  externi 
<!ATTLIST  externi 


-  0  (externl?)> 
consname  CDATA  #IMPLIED> 

-  0  (#PCDATA)> 

loc       ENTITY  #CONREF> 
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Annex  A 
Amendments  and  corrigenda 

(This  annex  forms  an  integral  part  of  this  specification.) 
A.1  Amendments 

AJ.1  Amendments  to  the  base  standard 

The  amendments  app!icab!e  to  this  CCITT  Recommendation  |  ISP  includes  the  ISO  8613  -  Amendment 
1:  1990.  This  amendment  includes  text  to  be  included  in  ISO  8613-1  as  the  following  annexes: 

—  Annex  E:  Use  of  ISO/IEC  10021  (MOTIS)  to  interchange  documents  conforming  to  ISO 
8613; 

—  Annex  F:  Document  Application  Profile  proforma  and  notation; 

—  Annex  G:  Conformance  testing  methodology; 

—  Annex  H:  Recording  of  documents  conforming  to  ISO  8613  on  flexible  disk  cartridges 
conforming  to  ISO  9293. 

In  addition,  this  amendment  addresses  the  inclusion  of  the  ISO  8613  Technical  Corrigenda  1. 
This  ISP  does  not  include  the  following  features  of  the  amendment: 

—  addendum  on  security; 

—  addendum  on  styles; 

—  addendum  on  alternative  representation; 

—  addendum  on  colour; 

—  addendum  on  tiled  raster  graphics. 

A.1 .2  Proposed  changes  to  standards  due  to  defects 

Proposed  Technical  Corrigendum  No.  44  to  (ISO  861 3  |  T.410  recommendations]  dated  15  December  1991 
assumed  to  be  ratified  by  ISO. 
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A.2  Corrigenda 


A.2.1  Corrigenda  to  the  CCITT  Recommendation  |  ISP 

There  is  no  corrigendum  specific  to  this  CCITT  Recommendation  |  ISP. 


I 
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Annex  B 


Recommendations 


(This  annex  does  not  form  an  integral  part  of  this  specification.) 


B.1  Transfer  methods  for  ODA 


B.1.1  Conveyance  of  ODA  over  CCITT  X.400-1984 

This  recommendation  describes  how  ODA  body  parts  are  to  be  encoded  for  transmission  over  a  CCITT 
X.400-1984  service. 

An  ODA  body  part  is  encoded  as  OdaBodyPart  in  the  definition  given  below: 

GdaBodyPart  ;;=  SEQUENCE  {  OdaBodyPartParameters.  OdaData  } 
OdaBodyPartParameters  ::=  SET  { 
document-application-profile 

[0]  IMPLICIT  OBJECT  IDENTIFER. 
document-architecture-class 

(1)  IMPLICIT  INTEGER  { 
formatted  (0), 
processable  (1), 
formatted-processable  (2) } 
OdaData  ::=     SEQUENCE  OF  Interchange-Data-Element 

NOTE  33  -  It  is  recommended  to  transfer  an  ODA  document  as  a  single  body  part  with  tag  12: 

Oda  (12]  IMPLICIT  OCTETSTRING 

The  content  of  the  octet  string  is  encoded  as  OdaBodyPart,  defined  above.  However,  this  is  out  of  the 
scope  of  this  profile. 


B.1 .2  Conveyance  of  ODA  over  FTAM 

This  recommendation  describes  the  FTAM  Document  Type  to  be  used  for  minimal  storage  and  transfer 
capabilities  of  ODA  data  streams.  It  is  recognized  that  enhanced  capabilities  may  at  some  point  be  added. 

When  using  FTAM  to  transfer  an  ODA  file,  the  FTAM-3,  "ISO  FTAM  Unstructured  Binary",  document  type 
shall  be  specified. 

However,  since  files  that  do  not  contain  ODA  data  streams  can  have  the  same  document  type,  it  is  left  up 
to  the  user  of  application  programs  that  remotely  access  files  using  FTAM  to  know  that  a  given  file  contains 
an  ODA  data  stream. 
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B.1 .3  Conveyance  of  ODA  over  DTAM 


This  recommendation  provides  for  Information  concerning  the  interchange  of  ODA  based  documents  with 
DTAM  protocols. 

DTAM  (Document  Transfer  and  Manipulation)  is  defined  in  the  T.430-Series  of  recommendations  and  is, 
like  ODA.  an  integral  part  of  the  T.400-Series  of  CCITT  Recommendations  named  Open  Document 
Architecture,  Transfer  and  Manipulation. 

The  T.520-Series  of  recommendations  contain  Communication  Application  Profiles  (CAP). 
Recommendation  T.522  describes  the  Communication  Application  Profile  BT1  for  document  bulk  transfer. 
Recommendation  T.522  is  applicable  for  the  Office  Document  Format  Profile  (POD)  published  in  this  ISP. 

NOTE  34  -  The  use  of  BTI  within  the  end-to-end  oriented  Telematic  Services  Telefax  4  and  Teletex  is  described 
in  Recommendation  T.561,  subclause  7.1  and  Recommendation  T.562,  subclause  7.1. 


B.1.4  Conveyance  of  ODA  over  flexible  disks 

The  recommended  method  for  interchanging  ODA  documents  between  systems  by  the  exchange  of 
magnetically  recorded  Flexible  Disk  Cartridges  is  by  the  use  of  an  annex  to  [CCITT  Recommendation  T.41 1 
I  ISO  8613-1]  (to  be  published),  "Recording  of  Documents  Conforming  to  ISO  8613  on  Flexible  Cartridges 
Conforming  to  ISO  9293".  This  annex  provides  for  recording  each  ODA  document  as  a  separate  file  as 
defined  by  ISO  9293,  "Volume  and  File  Structure  of  Flexible  Disk  Cartridges  for  Information  Intercfiange". 

NOTE  35  -  Document  encoded  in  ODL  may  be  stored  such  that  each  SGML  ENTITY  is  recorded  in  a  separate 
file  or  in  the  case  of  an  SDIF  encoding,  the  file  may  be  stored  in  a  single  file. 


B.2  Font  reference 


The  recommended  method  for  specifying  a  font  reference  is  to  be  based  on  ISO  9541 . 

Font  sizes  from  6  to  72  points  (100  to  1200  BMU)  are  intended  to  be  supported  by  implementation 
conforming  to  this  recommendation.  All  other  values  of  font  sizes  may  additionally  be  supported,  but 
implementations  may  also  support  using  some  form  of  "fallback". 

The  minimum  font  properties  and  values  from  ISO  9541  that  are  to  be  specified  in  a  Font-Attribute-Set  are 
those  specified  by  the  following  document  application  profile  notation. 


Font-Attribute -Set  { 


PERM 

Font-Name 

{ANY  VALUE}, 

PERM 

Standard-Version 

{ANY  VALUE}. 

PERM 

Data-source 

{ANY  VALUE}, 

PERM 

Design-source 

{ANY_VALUE}. 

PERM 

Font-Family-Name 

{ANY_VALUE}, 

PERM 

Posture 

{'upright'  |  'italic-forward'}. 

PERM 

Weight 

{'light'  1  'medium'  |  'bold'}. 

PERM 

Proportionate-Width 

{ANY  VALUE}. 

PERM 

Glyph-Complement  { 

PERM  #lncluded-Glyph-Collections 
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{ANY_VALUE}. 
PERM  #Excluded-Glyph-Collections 

{ANY_VALUE}. 

PERM  #lncluded-Glyphs  {ANY_VALUE}. 
PERM  #Excluded-Glyphs  {ANY_VALUE} 


PERM  Design-Size 

PERM  Min-Size 

PERM  #Numerator 
PERM  #Denominator 

PERM  Max-Size 

PERM  #Numerator 
PERM  #Denominator 


{ANY_VALUE}. 
1200}. 


{100  .. 
{1} 


{100 
{1} 


1200}. 


-  BMU  Units  equivalent  to  range  of  6. .72  point  sizes 
PERM  Design-Group  { 

PERM  #Class  (ANY_VALUE}. 
PERM  #Subclass  {ANY_VALUE}. 
PERM  #Specific-Group  {ANY_VALUE} 


{ 


{ 


PERM  Structure 
PERM  Writing-Modes 
MUL 

REQ  #Writing-Mode-Name 

{ANY. 

PERM  #Nominal-Escapement 

{ANY. 

PERM  #Escapement-Class 

{ANY. 

PERM  #Average-Escapement 

{ANY. 

PERM  #Average-Escapement 

{ANY 
} 

} 

} 


{ANY_VALUE}. 


VALUE}. 
Direction 
VALUE}. 

VALUE}. 
X 

VALUE}. 
Y 

VALUE} 


B.3  ISO  8632  (CGM)  constraints  for  this  DAP 

It  is  recommended  that  geometric  graphics  content  information  contain  only  those  elements  listed  in  this 
portion  of  the  document,  in  addition  to  the  constraints  imposed  by  (CCITT  Recommendation  T.418  |  ISO 
8613-8].  It  is  believed  that  this  subset  of  the  CGM  is  sufficiently  implemented  to  enable  interworking  of 
geometric  graphics  for  application  conforming  to  this  document  application  profile. 

Where  an  element  has  parameters,  recommended  constraints  on  the  values  are  given.  The  "-"  symbol 
indicates  that  there  is  no  recommended  constraint. 

Requirements  in  ISO  8632  and  (CCITT  Recommendation  T.418  |  ISO  8613-8]  concerning  mandatory 
elements,  parameters  shall  be  fulfilled. 
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B.3.1  Delimiter  elements 

No-Op 

Begin  Metafile 


End  Metafile 
Begin  Picture 


Begin  Picture  Body 
End  Picture 


An  arbitrary  sequence  of  n  octets.  Where  n=0,  1,  ..,  32767.  Tfie 
sequence  of  zero  or  more  octets  is  for  padding  purposes. 
Support  will  be  provided  for  strings  witfi  a  length  up  to  254  octets, 
except  for  data  records  which  will  support  strings  with  a  length  up 
to  32767  octets. 

Support  will  be  provided  for  strings  with  a  length  up  to  254  octets, 
except  for  data  records  which  will  support  strings  with  a  length  up 
to  32767  octets. 


B.3.2  Metafile  descriptor  elements 


Metafile  Version 
Metafile  Description 


VDC  Type 
Integer  Precision 
Real  Precision 
Index  Precision 
Colour  Precision 
Colour  Index  Precision 
Maximum  Colour  Index 
Colour  Value  Extent 
Metafile  Element  List 
Metafile  Defaults  Replacement 
Font  List 


Character  Set  List 


Character  Coding  Announcer 


1 

Support  will  be  provided  for  strings  with  a  length  up  to  254  octets, 
except  for  data  records  which  will  support  strings  with  a  length  up 
to  32767  octets.  The  METAFILE  DESCRIPTION  string  parameter 
will  be  used  to  include  the  sub-string  "ISO  FOD36"  to  label  the 
content  information  as  conforming  to  this  profile.  In  addition, 
generators  of  content  are  encouraged  to  append  a  sub-string  that 
identifies  the  company  and  product  that  produced  the  CGM. 

16,  32 

(0,9,23),  (1,16,16) 
16 

8,  16 
8,  16 
0..63 


All  fonts  referenced  in  the  metafile  shall  be  defined.  Font 
referencing  in  FONT  LISTS  using  ISO  9541  names  is  preferred, 
but  font  names  may  be  specified  using  proprietary  font  names. 
All  character  sets  referenced  in  the  metafile  shall  be  defined  in 
CHARACTER  SET  LIST.  Permissible  character  sets  are  the 
same  as  for  character  content  architecture. 


B.3.3  Picture  descriptor  elements 

Scaling  Mode  The  Scale  Factor  parameter  of  SCALING  MODE  element  is 

always  a  32-bit  floating  point  value,  even  when  the  REAL 
PRECISION  has  selected  fixed  point  for  other  real  numbers.  It  is 
not  apparent  in  ISO  8632  what  the  precision  of  this  floating  point 
value  is  when  fixed  point  has  been  selected.  Its  precision  shall  be 
(0,9,23). 

Colour  Selection  Mode 

Line  Width  Specification  Mode 
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Marker  Size  Specification  Mode 
Edge  Widtli  Specification  Mode 
VDC  Extent 
Background  Cotour 


B.3.4  Control  elements 

VDC  Integer  Precision 
VDC  Real  Precision 
Auxiliary  Colour 
Transparency 
Clip  Rectangle 
Clip  Indicator 


16.  32 

(0.9.23),  (1.16.16) 
Transparent 


B.3.5  Graphical  primitive  elements 


Polyline 

Disjoint  Polyline 

Polymarker 

Text 


Restricted  Text 


Append  Text 


Polygon 
Polygon  Set 
Cell  Array 


Rectangle 
Circle 

Circular  Arc  3  Point 
Circular  Arc  3  Point  Close 
Circular  Arc  Centre 
Circular  Arc  Centre  Close 
Ellipse 
Elliptical  Arc 
Elliptical  Arc  Ck)se 


The  minimum  support  for  the  length  of  point  lists  is  1024  points. 
The  minimum  support  for  the  length  of  point  lists  is  1024  points. 
The  minimum  support  for  the  length  of  fxtint  lists  is  1024  points. 
Support  will  be  provided  for  strings  with  a  length  up  to  254  octets, 
except  for  data  records  which  will  support  strings  with  a  length  up 
to  32767  octets.  Format  effector  control  characters  are  disallowed 
in  the  string  parameter. 

Support  will  be  provided  for  strings  with  a  length  up  to  254  octets, 
except  for  data  records  which  will  support  strings  with  a  length  up 
to  32767  octets.  Format  effector  control  characters  are  disallowed 
in  the  string  parameter. 

Support  will  be  provided  for  strings  with  a  length  up  to  254  octets, 
except  for  data  records  which  will  support  strings  with  a  length  up 
to  32767  octets.  Format  effector  control  characters  are  disallowed 
in  the  string  parameter. 

The  minimum  support  for  the  length  of  point  lists  is  1024  points. 
The  minimum  support  for  the  length  of  point  lists  is  1024  points. 
The  minimum  support  for  the  length  of  colour  lists  parameter  for 
the  CELL  ARRAY  element  is  1048576.  This  supports  a  1024  x 
1024  image. 


B.3.6  Attribute  elements 

Line  Bundle  Index 

Line  Type  Negative  values  are  prohibited. 

Line  Width 


232 


Line  Colour 
Marker  Bundle  Index 
Marker  Type 
Marker  Size 
Marker  Cok)ur 
Text  Bundle  Index 
Text  Font  Index 


Text  Precision 
Character  Expansion  Factor 
Character  Spacing 
Text  Cobur 
Character  Height 
Character  Orientation 
Text  Path 
Text  Alignment 
Character  Set  Index 


Alternate  Character  Set  Index 


Fill  Bundle  Index 
Interior  Style 
Fill  Colour 
Hatch  Index 
Pattern  Index 
Edge  Bundle  Index 
Edge  Type 
Edge  Width 
Edge  Colour 
Edge  Visibility 
Fill  Reference  Point 
Pattern  Table 


Pattern  Size 

Colour  Table  Specification 


Negative  values  are  prohibited. 


All  fonts  referenced  (indexed  by  TEXT  FONT  INDEX)  in  the 
metafile  shall  be  defined  in  FONT  LIST  either  in  presentation 
parameters  of  [CCITT  Recommendation  T.410  series  |  ISO  8613] 
or  in  ISO  8632. 


All  character  sets  referenced  in  the  metafile  (indexed  by 
CHARACTER  SET  INDEX)  shall  be  defined  in  CHARACTER  SET 
LIST.  The  only  character  sets  which  may  be  designated  in  GO 
are  ISO  646  IRV  or  versions  of  ISO  646.  Other  character  sets 
shall  be  designated  in  G1.  G2  or  G3. 

All  character  sets  referenced  in  the  metafile  (indexed  by 
ALTERNATE  CHARACTER  SET  INDEX)  shall  be  defined  in 
CHARACTER  SET  LIST. 


Negative  values  are  prohibited. 
1  ..  8 


Negative  values  are  prohibited. 


The  PATTERN  TABLE  element  has  an  unspecified  effect  when  it 
appears  in  a  picture  subsequent  to  any  graphical  primitives.  The 
PATTERN  TABLE  element  shall  appear  prior  to  any  graphical 
primitive  element  to  assure  that  interpreting  systems  without 
dynamic  pattern  update  can  render  the  intended  effect.  The 
minimum  support  for  the  length  of  the  Colour  Array  parameter  for 
the  PATTERN  TABLE  element  is  2048.  This  will  support  8 
patterns  of  16  x  16,  2  patterns  of  32  x  32  or  1  pattern  of  32  x  64. 
All  indexes  which  are  used  in  the  metafile  shall  be  defined. 

The  COLOUR  TABLE  element  has  an  unspecified  effect  when  It 
appears  In  a  picture  subsequent  to  any  graphical  primitives.  The 
COLOUR  TABLE  element  shall  appear  prior  to  any  graphical 
primitive  elements  to  assure  that  interpreting  systems  without 
dynamic  colour  update  can  render  the  intended  effect.  The 
minimum  support  for  the  length  of  the  Colour  List  parameter  in  the 
COLOUR  TABLE  element  is  63.  This  will  support  a  64  (0..63) 
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entty  colour  table.  All  indexes  which  are  used  in  the  metafile  shall 
be  defined. 


Aspect  Source  Flags 


B.3.7  External  elements 


Message 


The  presentation  of  message  string  may  not  be  appropriate  for  ail 
applications.  No  requirement  for  formatted  presentation  of  the 
message  string  has  been  placed  on  the  Interpreter.  Only  the  No 
Action  flag  needs  to  be  supported.  Support  for  string  lengths  up 
to  254. 


Application  Data 


Support  will  be  provided  for  strings  with  a  length  up  to  254  octets, 
except  for  data  records  which  will  support  strings  with  a  length  up 
to  32767  octets. 


B.4  Interoperability  with  SGML  applications 

NOTE  36  -  Annex  B.4  applies  to  the  ISP  only. 

The  recommended  method  for  the  exchange  of  documents  between  Standard  Generalized  Markup 
Language  (ISO  8879.  SGML)  based  systems  and  systems  based  on  this  ODA  document  application  profile 
is  by  means  of  exchanging  a  document  representation  conforming  to  these  agreements  in  an  encoded  form 
of  the  SGML  language  known  as  the  Office  Document  Language  (ODL)  ODL  is  a  standardized  SGML 
application  for  representing  documents  conforming  to  the  ODA  base  standard  Such  a  representation  may 
be  converted  into  the  Office  Document  Interchange  Format  (ODIF)  supported  by  this  document  application 
profile.  ^ 
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PART  17  -  Office  Document  Architecture 
Level  2  DAP 


December  1992  (Stabie) 


Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Office  Document  Architecture 
Special  Interest  Group  (ODASIG)  of  the  Open  Systems  Environment  Implementors'  Wori<shop  (OIW). 

Text  in  this  part  has  been  approved  by  the  Plenary  of  the  above-mentioned  Workshop. 

Future  changes  and  additions  to  this  version  of  these  implementor  Agreements  will  be  published  as  change 
pages.  Deleted  and  replaced  text  will  be  shown  as  struckout.  New  and  replacement  text  will  be  shown  as 
shaded. 
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Part  17  -  Office  Document  Architecture  Level  2  DAP 


NOTE  -  Text  for  the  International  Standardized  Profile  1 1 181-1  (FOD26)  follows  this  page. 

This  Agreement  provides  a  Document  Application  Profile  which  has  been  developed  through  the 
joint  efforts  of  ODA  expert  groups  within  the: 

OSE  Implementors'  Workshop  (OiW); 

Asia-Oceania  Workshop  (AOW); 

European  Workshop  for  Open  Systems  (EWOS); 

CCITT  Study  Group  VIII. 

This  effort  was  conducted  through  meetings  of  the  Profile  Alignment  Group  for  ODA  (PAGODA)  for 
the  purpose  of  facilitating  the  inten^^orking  of  applications  which  interchange  documents  based  on 
[ISO  8613  I  T.410  series  of  CCITT  Recommendations].  This  Agreement  specifies  one  of  the 
profiles  resulting  from  that  work: 

ISO/IEC  ISP  111  81-1 : 1 992.  Information  technology- Standardized  Profile  FOD36- Office  Document 
Format:  Enhanced  document  structure -Character,  raster  graphics  and  geomentric  graphics  content 
architectures  -  Document  Application  Profile. 


This  Agreement  accepts  the  entirety  of  the  definitions  and  provisions  of  this  ISP  as  the  agreement 
for  the  OIW  Stable  Agreements  and  the  standards  upon  which  the  specified  ISP  is  based  as 
referenced  by  the  text  of  the  ISP.  For  this  reason  the  text  of  the  ISP  is  not  reproduced  here,  but 
referenced  to  avoid  any  doubt  as  to  the  official  text  being  agreed  upon. 
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Foreword 


Development  of  this  document  application  profile  has  been  done  in  liaison  with 
several  organizations.    These  include  ODA  expert  groups  within  the: 

-  ;  Asia-Oceania  Workshop  (AOW); 

CCITT  Study  Group  VIII; 

-  Europeem  Workshop  for  Open  Systems  (EWOS); 

-  NIST  OSI  Implementors  Workshop  (OIW). 

The  liaison  between  these  organizations  has  occurred  within  the  meetings  of  the 
Profile  Alignment  Group  for  ODA  (PAGODA) .    These  meetings  have  focused  on  the 
development  of  a  single  set  of  Internationally  aligned  ODA  document  application 
profiles . 

The  profile  defined  in  this  ISP  is  a  part  of  the  ODA  profile  taxonomy  defined  in 
TR  10000-2,  4.4.4.3  and  5.4.1.    This  profile  is  specific  to  the  profile 
identifier  FOD26. 

At  present,  this  ISP  consists  of  one  part: 

-  part  1,  Document  application  profile. 
Further  parts  nay  be  added  to  this  ISP. 

This  part  contains  three  annexes: 


-         annex  A  (normative):  Amendments  and  corrigenda 
•         annex  B  (informative):  Recommendations; 
- '        annex  C  ( informative ) :  Bibliography . 
Introduction 

The  purpose  of  this  International  Standardized  Profile  (ISP)  is  to  facilitate 
the  interworking  of  applications  interchanging  documents  based  on  ISO  8613,  ODA. 
This  ISP  is  suitable  for  interchanging  documents  in  formatted  foznn,  processable 
form  or  formatted  processable  form  and  has  been  defined  in  accordance  with  [ISO 
8613-1 jcciTT  Recommendation  T.411].    The  format  of  this  profile  is  in  accordance 
with  the  standardized  proforma  and  notation  defined  in  Addendum  1-Annex  F  of 
[ISO  8613-1 jcciTT  Recommendation  T.411]. 
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International  Standardized  Profile  (ISP) 
FOD26: 

Information  technology  - 

International  Standardized  Profile  FOD26  - 
Office  Document  Format:  Enhanced  Document  structure  - 
Cheiracter,  Raster  Graphics  and  Geometric  Graphics 
content  architectures 


Part  1: 

Document  implication  Profile 
1  Scope 

This  profile  specifies  interchange  formats  for  the  transfer  of  structured 
documents  between  equipment  designed  for  word  or  document  processing.  Such 
docviments  may  contain  character,  raster  graphics  and  geometric  graphics  content. 

The  documents  that  can  be  interchanged  using  this  profile  range  from  simple 
docxunents  to  highly  structured  technical  reports,  articles  and  typeset  documents 
such  as  brochures.    This  profile  provides  a  comprehensive  level  of  features  for 
the  treuisfer  of  documents  between  these  systems. 

This  profile  allows  documents  to  be  interchanged  in  the  following  forms: 

a)  formatted  form; 

b)  processable  form; 

c)  formatted  processable  form. 

The  architecture  levels  defined  for  these  three  forms  have  matching 
functionalities  so  that  the  interchange  formats  of  a  document  are  convertible 
from  a  processable  form  to  any  other  form. 

This  profile  is  independent  of  the  processes  carried  out  in  an  end  system  to 
create,  edit  or  reproduce  documents.    It  is  also  independent  of  the  means  to 
transfer  documents  which,  for  example,  may  be  by  means  of  communication  links  or 
storage  media. 

A  document  structured  in  accordance  with  this  ISP  is  represented  for  interchemge 
by  one  of  two  DAPs.    One  DAP  uses  the  office  Docviment  Interchange  Format  (ODIF), 
the  other  DAP  uses  the  Office  Document  Language  (ODL),  both  as  defined  in  ISO 
8613-5. 

When  this  document  refers  to  this  profile,  it  is  referring  to  either  of  the 
document  application  profiles  defined  by  this  specification. 
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2       NoEsiative  Hisferences 

The  following  documents  contain  provisions  which,  through  reference  in  this  text 
constitute  provisions  of  this  Specification.    At  the  time  of  publication  the 
editions  indicated  were  valid.    All  docmnents  are  subject  to  revision  and 
parties  to  agreements  based  on  this  specification  are  warned  against 
automatically  applying  any  more  recent  editions  of  the  documents  listed  below, 
since  the  nature  of  references  made  by  profiles  to  such  documents  is  that  they 
nay  be  specific  to  a  particular  edition.    Members  of  lEC  and  ISO  maintain 
registers  of  currently  valid  International  Standards  and  ISPs.    The  CCITT 
secretariat  maintains  a  list  of  currently  valid  CCITT  recommendations. 

ISO  8613-1  :  1989,  Information  processing  -  Text  and  office  systems;  Office 
Document  Architecture  (ODA)  and  interchange  format  -  Part  1:  Introduction  and 
general  principles; 

ISO  8613-2  :  1989,  Information  processing  -  Text  and  office  systems;  Office 
Document  Architecture  (ODA)  and  interchange  format  -  Paurt  2:  Document 
structures ; 

ISO  8613-4  :  1989,  Information  processing  -  Text  and  office  systems;  Office 
Document  Architecture  (ODA)  and  interchange  format  -  Part  4:  Document  profile; 

ISO  8613-5  :  1989,  Information  processing  -  Text  and  office  systems;  Office 
Document  Architecture  (ODA)  and  interchange  format  -  Part  5:  Office  document 
interchange  format; 

ISO  8613-6  :  1989,  Information  processing  -  Text  and  office  systems;  Office 
Dociiment  Architecture  (ODA)  and  interchange  format  -  Part  6:  Character  content 
circhitectures ; 

ISO  8613-7  ;  1989,  Information  processing  -  Text  and  office  systems;  Office 
Document  Architecture  (ODA)  and  interchange  format  -  Part  7:  Raster  graphics 
content  architectures; 

ISO  8613-8  s  1989,  Information  procesainf  -  Text  and  office  systems;  Office 
Document  Architecture  (ODA)  and  interchange  format  -  Part  8:  Geometric  graphics 
content  architectures; 

ISO  8613-1  :  Addendum  1:    Information  processing  -  Text  and  office  systems; 
Office  Document  Architecture  (ODA)  and  interchange  format  Part  1:  Introduction 
and  general  principles.  Addendum  1  -  Annex  F:  A  Document  Application  Profile 
proforma  and  notation; 

CCITT  Recommendation  T.4  -  standeurdization  of  group  3  facsimile  apparatus  for 

document  transmission  (1988); 

CCITT  Reconmendation  T,6  -  Facsimile  coding  schemes  and  coding  control  functions 
for  group  4  facsimile  apparatus  (1988); 

ISO/IEC  646  J  1991,  Information  technology  -  ISO  7 -bit  coded  character  set  for 
information  interchange; 
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ISO  8859-1  %  1987,  Information  processing  -  8-bit  Single-byte  coded  graphic 
character  sets  -  Part  1:  Latin  alphabet  No.  1; 

ISO  6937-2  :  1983,  Information  processing  -  Coded  character  sets  for  text 
cosununication  -  Part  2:  Latin  alphabetic  and  non-alphabetic  graphic  characters; 

ISO  6937-2  Addendum  1  :  1989,  Information  processing  -  Coded  character  sets  for 
text  communication  -  Part  2 :  Latin  alphedaetic  and  non-alphabetic  graphic 
characters.  Addendum  1; 

ISO  2022  :  1986,  Information  processing  -  ISO  7-bit  and  8-bit  coded  character 
sets  -  code  extension  techniques; 

ISO  2375  :  1985,  Data  processing  -  Procedure  for  registration  of  escape 
sequences; 

ISO  7350  :  1984,  Text  communication  -  Registration  of  graphic  character 
subrepertoires ; 

ISO  8824  :  1987,  Information  processing  systems  -  open  Systems  Interconnection  - 
As tract  Syntax  Notation  One  (ASN.l); 

ISO  8825  :  1987,  Information  processing  systems  -  Open  Systems  Interconnection  - 
Basic  encoding  rules  for  abstract  syntax  notation  one  (ASN.l); 

ISO  8879  :  1986,  Information  processing  -  Text  and  office  systems  -  Standard 
Generalized  Markup  Language  (SGML); 

ISO  9069  :  1988,  Information  processing  -  SGML  support  facilities  -  SGML 
Document  Interchange  Format  ( SDIF ) ; 

ISP  10610-1  i  1992,  Information  technology  -  International  Standardized  Profile 
POD 11  -  office  Document  Format:  Simple  document  structure  -  Character  content 
architecture  only  -  Part  1:  Document  Application  Profile. 

ISP  11182-1  :  1992,  Information  technology  -  International  Standardized  Profile 
FOD36  -  Office  Document  Format:  Extended  document  structure  -  Chcuracter,  Raster 
Graphics  and  Geometric  Graphics  content  architectures  -  Part  1:  Document 
Application  Profile. 

ISO/IEC  TR  10000-1:  1990,  Information  Technology  -  Framework  and  taxonomy  of 
International  Standardized  Profiles  -  Part  1:  Framework 

ISO/IEC  TR  10000-2:  1990,  Information  Technology  -  Framework  and  taxonomy  of 
International  Standardized  Profiles  -  Part  2  Taxonomy  of  Profiles 
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3  Definitions 


For  the  purposes  of  this  Specification,  the  following  definitions  apply. 

The  definitions  given  in  [ISO  8613-1 |CCITT  Recommendation  T.411]  eure  applicable 
to  this  profile. 

Constituent  names 

Each  constituent  that  may  be  included  in  a  document  that  conforms  to  this 
profile  has  been  given  a  unique  name  which  serves  to  identify  that  constituent 
throughout  this  profile. 

The  convention  is  that  full  names  are  used  (i.e.,  no  £Q}breviations  are  used), 
two  or  more  words  in  a  name  are  concatenated  and  each  word  begins  with  a 
capital.  Examples  of  constituent  names  used  in  this  profile  are  BodyText, 
Footnote,  RectoPage  and  ColumnFixed. 

In  clause  6  each  constituent  provided  by  this  profile  is  underlined  once  at  the 
point  in  the  text  at  which  the  purpose  of  that  constituent  is  defined.  This 
also  serves  to  identify  all  the  constituents  provided  by  this  profile. 

The  same  constituent  names  are  also  used  in  the  technical  specification  in 
clause  7  so  that  there  is  a  one-to-one  correspondence  between  the  use  of  these 
names  in  clause  6  and  7. 

Although  the  constituent  names  relate  to  the  purpose  of  the  constituents,  the 
semantics  of  constituents  shall  not  be  implied  from  the  actual  names  that  are 
used.  Also,  these  names  do  not  appear  in  an  interchanged  dociiment  but  a 
mechanism  for  identifying  constituents  in  an  interchange  document  is  provided 
(see  6.6.4).    Thus  in  an  application  using  this  profile,  the  constituents  may  be 
known  to  the  user  by  different  names. 

4       Relationship  with  other  profiles 

This  profile  belongs  to  a  series  of  hierarchically  related  profiles  which 
include  FDD 11  and  FOD36. 

The  features  supported  by  this  profile  are  a  superset  of  the  features  supported 
by  the  profile  FODll  and  thus  all  data  streams  that  are  conformant  to  FODll  are 
also  conformant  to  this  profile,  apart  from  the  DAP  identifier. 

Also  the  features  supported  by  this  profile  are  a  subset  of  the  features 
supported  by  the  profile  FOD36  and  thus  all  data  streams  conformant  to  this 
profile  are  also  conformant  to  FOD36,  apart  from  the  DAP  identifier. 

The  specification  of  the  DAPs  in  this  isP  is  identifical  to  the  specification 
defined  in  the  CCITT  Recommendation  T.505  (PM-26),  except  that  PM-26  only 
defines  the  use  of  the  ODIF  interchange  format. 
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5  Conformance 

In  order  to  confora  to  this  profile,  a  data  stream  representing  a  document  shall 
meet  the  requirements  specified  in  5.1. 

This  part  of  the  ISP  does  not  define  implementation  support  requirements.  These 
requirements  are  defined  in  other  parts  that  make  use  of  this  ISP. 


5.1     Data  stream  conformance 

The  following  requirements  apply  to  the  encoding  of  data  streams  which  conform 
to  this  profile: 

a)  The  data  stream  shall  be  encoded  either  in  accordance  with  the  ASN.l 
encoding  rules  defined  in  ISO  8825  or  the  SGML  encoding  rules  defined 
in  ISO  8879; 

b)  The  data  stream  shall  be  structured  in  accordance  with  the 
interchange  formats  defined  in  clause  8; 

c)  The  document,  as  represented  by  the  data  stream  after  resolution  of 
any  external  references,  shall  be  structured  in  accordance  with  one 
of  the  documents  architecture  classes  as  defined  in  6.1  and  shall 
contain  all  mandatory  constituents  specified  for  that  class;  other 
constituents  may  be  included,  provided  that  they  are  permitted  for 
that  class,  as  specified  in  clause  7; 

d)  Each  constituent  shall  contain  all  those  attributes  specified  as 
required  for  that  constituent  in  this  profile;  other  attributes  may 
be  specified  provided  that  they  are  permitted  for  that  constituent; 

e)  The  attribute  values  specified  shall  be  within  the  range  of 
permissible  values  specified  in  this  profile; 

f )  The  encoded  document  shall  be  constructed  in  accordance  with  the 
abstract  doctiment  architecture  defined  in  [ISO  8613-2  |CCITT 
Recommendation  T.412]; 

g)  The  document  shall  be  structured  in  accordance  with  the 
characteristics  and  constraints  specified  in  clause  6. 
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5.2      In^lenentation  confoniance 

This  subclause  states  the  reguirenents  for  inpleinentations  claiming  conformance 
to  this  profile. 

A  conforming  receiving  implementation  shall  be  capable  of  receiving  either  any 
data  streams  conforming  to  this  profile  structured  in  accordance  with  ODIF  or 
any  data  streams  conforming  to  this  profile  structured  in  accordance  with  ODL  or 
both  of  these.    Receiving  usually,  but  not  always,  involves  recognizing  and 
further  processing  the  data  stream  elements.    The  explicit  meaning  of 
"receiving"  is  determined  by  another  part  of  this  ISP. 

A  receiving  system  which  claims  conformance  to  this  DAP  shall  be  capable  of 
hemdling  data  streams  which  are  conformant  to  DAPs  that  are  subordinate  to  this 
DAP  within  the  taxonomy  described  in  clause  4,  (ie.  FODll). 


6       Characteristics  supported  by  this  document  application  profile 

This  clause  describes  the  characteristics  of  documents  which  may  be  represented 
by  data  streams  conforming  to  this  profile.  This  clause  also  describes  how  these 
characteristics  are  represented  in  terms  of  constituent  constraints. 

6.1    Overview  \ 

6.1.1  General 

This  profile  supports  the  interchange  of  documents  in  the  following  forms: 

-         processable  form,  which  facilitates  the  revision  of  a  document  by  a 
recipient; 

"         formatted  form,  which  facilitates  the  reproduction  of  a  document  as 
intended  by  the  originator; 

formatted  processable  form,  which  facilitates  the  reproduction  of  a 
document  as  intended  by  the  originator  or  facilitates  the  revision  of 
a  document  by  a  recipient. 

In  addition  this  profile  supports  the  interchange  of: 

*•         generic -documents; 

*         document  profile. 

The  constituents  that  make  up  these  five  classes  of  data  stream  are  defined  in 

6.1.2  to  6.1.6.  Constituents  defined  as  'required'  shall  occxir  in  any  data 
stream  that  conforms  to  this  profile,  constituents  listed  as  'optional'  may  or 
may  not  be  present  in  the  data  stream  depending  on  the  requirements  of  the 
particular  data  stream. 
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Note  that  the  constituents  that  make  up  a  complete  document  that  is  conformant 
to  this  profile  include  all  those  referenced  and  contained  in,  if  any,  resource 
and  external  doctiments  (see  6.6.1  and  6.6.2). 

6.1.2    Formatted  form  documents 
Required  constituents: 

-  a  document  profile; 

-  layout  object  descriptions  representing  a  specific  layout  structure. 
Optional  constituents: 

-  layout  object  class  descriptions  representing  a  'factor'  generic 
layout  structure; 

-  presentation  styles; 

-  content  portion  descriptions. 


€.1.3    Processable  form  documents 
Required  constituents: 

-  a  document  profile; 

-  logical  object  class  descriptions  representing  a  'complete'  or 
'partial'  generic  logical  structure; 

-  logical  object  descriptions  representing  a  specific  logical 
structure . 

Optional  constituents: 

-  layout  object  class  descriptions  representing  a  'complete'  generic 
layout  structure; 

-  layout  styles; 
presentation  styles; 

-  content  portion  descriptions. 

In  the  case  of  processable  form  documents,  when  the  generic  layout  structure  is 
not  present,  additional  restrictions  sire  placed  on  the  layout  directives  that 
may  be  included  in  layout  styles.  These  restrictions  are  defined  in  6.4.3. 
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6.1.4  Formatted  procesaable  form  documenta 
Required  constituents: 

*  a  docvuaent  profile; 

-  logical  object  class  descriptions  representing  a  'complete'  or 
'partial'  generic  logical  structure; 

-  logical  object  descriptions  representing  a  specific  logical 
structure; 

•  layout  object  class  descriptions  representing  a  'complete'  generic 
layout  structure; 

"         layout  object  descriptions  representing  a  specific  layout  structure. 
Optional  constituents: 

-  layout  styles; 

-  presentation  styles; 

-  content  portion  descriptions. 

6.1.5  Generic -documents 

A  generic -document  consists  of  one  of  the  following  sets  of  constituents: 
a) 

-  a  document  profile; 

logical  object  class  descriptions  which  represent  a  'complete' 
or  'partial'  generic  logical  structure; 

-  layout  styles  whose  presence  is  optional; 
presentation  styles  whose  presence  is  optional; 

-  generic  content  portions  whose  presence  is  optional. 


b) 


a  document  profile; 

layout  object  class  descriptions  which  represent  a  'complete' 
generic  layout  structure  or  'factor'  set; 

presentation  styles  whose  presence  is  optional; 

generic  content  portions  whose  presence  is  optional. 
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a  document  profile; 

-  logical  object  class  descriptions  which  represent  a  'complete' 
or  'partial'  generic  logical  structure; 

-  layout  object  class  descriptions  which  represent  a  'complete' 
generic  layout  structure; 

-  layout  styles  whose  presence  is  optional; 

-  presentation  styles  whose  presence  is  optional; 

-  generic  content  portions  whose  presence  is  optional. 

6.1.6    Document  profile 

This  form  of  document  contains  a  document  profile  only., 

6.2    Logical  characteristics 

6.2.1  Introduction 

This  subclause  defines  the  logical  constituent  constraints  provided  by  this 
profile  to  represent  the  characteristics  of  documents  containing  logical 
component  descriptions . 

Different  constituent  constraints  may  be  used  to  represent  and  distinguish  parts 
of  a  document  that  have  different  logical  characteristics.    This  subclause 
describes  the  general  characteristics  and  typical  uses  of  the  constituent 
constraints  that  are  provided. 

The  descriptions  of  the  logical  characteristics  represented  by  each  of  the 
constituent  constraints  is  provided  for  guidance  only.  It  is  the  responsibility 
of  the  user  to  determine  how  a  docviment  is  to  be  represented  using  the 
constituents  provided.  Adherence  to  these  guidelines  can  enhance  the  mutual 
understanding  of  a  doc\iment  by  an  originator  and  a  recipient. 

6.2.2  Overview  of  the  logical  structure 

From  the  logical  point  of  view,  the  document  consists  of  two  parts,  namely  a 
'body  part  and  a  'common'  peurt. 

The  'body  part  represents  the  main  content  of  a  document  and  is  intended  to  be 
reproduced  in  the  body  area  of  the  pages  that  make  up  the  document. 

The  'common'  part  represents  common  content  that  is  to  be  placed  in  reserved 
header  and  footer  areas  on  each  page  of  a  document.  Header  and  footer  content 
are  independently  optional  and  so  may  be  included  in  an  interchanged  document 
only  if  required. 
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6.2.3    Body  pari:  of  -the  logical  structure 

6.2.3.1  DoctunentlioglcalRoot 

DocvunentLogicalRoot  is  a  constituent  constraint  representing  the  top  level  in 
the  document  logical  structure.  Its  immediate  subordinates  consist  of  a  sequence 
of  one  or  more  constituent  constraints  of  the  type  Passage. 

The  automatic  nvimbering  schemes  that  apply  to  constituent  constraints  of  the 
types  NumberedSegment  and  Footnote  may  be  initialised  on  the 
DocumentLogicalRoot . 

6.2.3.2  Passage 

Passage  is  a  constituent  constraint  that  represents  the  first  level  of  logical 
subdivision  of  a  document.  It  may  be  used  to  indicate  a  logical  grouping  of 
subordinate  parts  of  a  document  that  are  to  be  regarded  as  an  entity  for  reading 
or  that  have  common  layout  and  presentation  characteristics.  For  example: 

Passages  are  typically  used  to  represent: 

the  contents  to  be  placed  on  the  title  page  of  a  report; 

-  the  front  matter  in  the  taJale  of  contents  or  foreword; 

-  the  main  matter  of  the  document; 

-  the  back  matter,  consisting  of  appendices,  glossary  or  index. 

The  automatic  numbering  schemes  that  apply  to  subordinate  constituent 
constraints  of  the  types  NumberedSegment  and  Footnote  may  be  initialised  on  a 
Passage. 

The  immediate  subordinates  of  a  Passage  consist  of  an  optional  arbitrary  ordered 
sequence  of  one  or  more  of  the  following  constituent  constraint  types: 

Paragraph; 

-  BodyGeometric ; 

-  BodyRaster; 

-  BodyText. 

These  may  be  optionally  followed  by  one  or  more  constituent  constraints  of  the 
type  NumberedSegment. 

A  Passage  shall  have  at  least  one  of  the  above  constituent  constraint  types  as  a 
subordinate . 

A  document  may  contain  several  different  class  definitions  of  the  type  Passage, 
each  of  which  defines  the  common  characteristics  of  sets  of  Passages  within  the 
document  such  as  their  allowed  subordinates  or  layout  properties.  For  example,  a 
class  of  Passages  may  be  defined  which  always  begin  on  a  new  page  set. 
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6.2.3.3  NumberedSegment 

NumberedSegment  is  a  constituent  constraint  that  represents  a  logical 
subdivision  within  a  document  that  is  distinguished  by  an  identifier.  The 
logical  subdivision  nay  be  a  subdivision  of  a  Passage  or  another  higher  level 
NumberedSegment.    The  logical  subdivision  may  also  have  some  common  layout 
characteristics. 

The  automatic  numbering  schemes  that  apply  to  subordinate  constituent 
constraints  of  the  types  NumberedSegment  and  Footnote  may  be  initialised  on  a 
Passage. 

The  immediate  subordinates  of  a  NumberedSegment  consist  of  the  constituent 
constraint  Number,  whose  presence  is  mandatory  and  serves  to  ceurry  the 
identifier  of  the  NumberedSegment.  This  is  followed  by  an  optional  arbitrary 
ordered  sequence  of  one  or  more  of  the  following  constituent  constraints : 

Paragraph; 

-  BodyGeometric ; 
BodyRaster; 

-  BodyText . 

These  are  optionally  followed  by  a  sequence  of  one  or  more  constituent 
constraints  of  the  type  NumberedSegment.  Hence  a  document  may  contain  any  number 
of  nested  levels  of  the  constituent  NumberedSegment. 

A  NumberedSegment  is  typically  used  to  represent  entities  such  as  chapters, 
sections,  nested  sub-sections  and  appendices  which  contain  an  identifier  that 
serves  to  distinguish  that  entity  for  human  comprehension. 

A  document  may  contain  any  number  of  different  class  definitions  of 
NumberedSegment  which  define  the  common  characteristics  of  sets  of 
NumberedSegments ,  such  as  their  allowed  subordinates  and  layout  properties. 

Class  definitions  of  NumberedSegments  may  be  recursively  defined.     In  this  case 
only  one  call  of  NumberedSegment  may  be  specified,  and  the  <simple-expr> 
construction  in  the  macro  USENUMBERSTRINGS  in  the  bindings  attribute  of  this 
class  shall  use  the  optional  ORD  construction  only.     If  the  recursive  class 
definitions  are  used  for  NumberedSegment,  the  following  constraints  will  also 
apply.    For  all  levels  which  reference  recursively  defined  classes; 

-  numbering  format  will  be  the  same; 

-  no  initial  value  other  than  1  or  re-initialisation  of  the  numbering  is 
possible; 

-  it  is  not  possible  to  continue  the  numbering  across  Passages. 

If  class  definitions  are  not  recursive  in  this  way,  there  shall  be  one  and  only 
one  class  definition  for  NumberedSegements  corresponding  to  each  level  of 
numbering  within  each  Passage.     Class  definitions  may  be  shared  between 
NumberedSegments  belonging  to  different  Passages  but  they  shall  then  be  used  at 
the  same  level. 
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€.2.3.4  Number 

Number  is  a  constituent  constraint  that  represents  the  identifier  of  a 
Numberedsegment  to  which  it  is  subordinate.  This  identifier  allows  the 
NumberedSegment  to  be  distinguished  within  the  document  for  machine  processing 
or  human  comprehension. 

A  Number  is  a  basic  logical  constituent  which  contains  a  content  generator 
which,  when  evaluated,  produces  the  identifier  referred  to  above.  This 
evaluation  takes  place  during  the  layout  process. 

The  identifiers  are  structured  and  consist  of  a  sequence  of  one  or  more  numerals 
that  allow  NumberedSegments  at  the  same  or  different  levels  in  a  document 
structure  to  be  uniquely  distinguished.  The  nxmerals  may  be  represented  by 
Arabic  or  Rometn  numerals  or  by  their  alphabetic  equivalent  in  lower  or  upper 
case  characters  (the  niimber  1  is  represented  by  'A'  etc.).  Each  numeral  in  an 
identifier  is  distinguished  by  means  of  'separator'  characters  such  as  spaces 
and  full  stops  (the  character  "period");  a  typical  example  is  '6.2.3.4'. 

^OTEt  The  separator  may  if  required  be  an  empty  string. 

Further  details  of  the  structure  and  generation  of  the  identifiers  are  given  in 
6.6.7. 

6.2.3.5  Paragraph 

Peuragraph  is  a  constituent  constraint  that  is  a  subdivision  of  a  Passage  or 
NumberedSegment.  It  is  typically  used  to  represent  the  grouping  of  peirts  of  a 
document  that  deals  with  a  single  theme  or  topic.  These  parts  may  consist  of 
character,  raster  graphics  and  geometric  graphics  content. 

The  immediate  subordinates  of  a  Paragraph  consist  of  an  arbitrary  ordered 
sequence  of  one  or  more  of  the  following  constituent  constraints: 

BodyText; 

BodyRaster; 
-  BodyGeometric; 
r  Footnote. 

Content  from  any  subordinate  basic  text  objects  within  a  paragraph  ma^  be  run  on 
one  from  another  (that  is,  to  continue  on  the  same  line)  by  use  of  the 
Concatenation  feature  (see  6.4.2.5).    Alternatively,  content  from  subordinates 
of  a  paragraph  may  be  separated  one  from  another  to  give  white  space  between 
them,  using  Separation  (see  6.4.2.2).    This  may  be  used  to  give  an  effect 
similar  to  that  achieved  with  empty  lines  of  text.    Use  of  empty  text  lines  to 
achieve  white  space  between  areas  of  text  or  other  content  ma;^  lead  to 
unintended  blank  areas  adjacent  to  the  leading  edge  of  layout  objects  (eg  at 
page  breaks)  whereas  the  use  of  Sepeuration  avoids  this. 
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Constituents  of  the  type  BodyText  may  be  'concatenated'  to  form  a  continuous 
stream  of  character  content  which  is  laid  out  as  a  single  unit,  sequences  of 
constituents  of  the  types  BodyText  and  Footnote  may  be  concatenated  to  represent 
a  streaon  of  character  content  with  embedded  footnotes .  Multiple  embedded 
footnotes,  which  may  be  consecutive  without  intervening  text,  may  be  included  in 
the  content. 

Another  typical  use  of  a  Paragraph  is  to  represent  a  group  of  document  parts 
that  have  common  layout  characteristics^.  An  example  is  a  graphical  illustration 
with  associated  text  which  is  to  be  laid  out  in  a  particular  frame. 


6.2.3.6  BodyText,  BodyRaster  and  BodyGeometric 

BodyText,  BodyRaster  and  BodyGeometric  are  constituent  constraints  which 
represent  the  lowest  level  of  logical  subdivision  of  a  document.  These 
constituent  constraints  are  subdivisions  of  Passages,  NumberedSegments  and 
Paragraphs.  They  allow  the  layout  and  presentation  requirements  of  different 
parts  of  a  document  to  be  specified. 

These  are  basic  logical  constituents  that  directly  refer  to  content  portions 
that  contain  character,  raster  graphics  and  geometric  graphics  content 
respectively.  BodyText  shall  refer  to  one  or  more  content  portions  each 
containing  processetble,  formatted  or  formatted  processable  character  content. 
BodyRaster  and  BodyGeometric  shall  only  refer  to  a  single  content  portion 
containing  formatted  processcible  raster  graphics  content  or  formatted 
processable  geometric  graphics  content  respectively. 

Constituents  of  these  types  in  the  generic  logical  structure  may  refer  to 
generic  content.  This  provides  the  means  of  defining  common  content  within  the 
body  part  of  a  docviment. 

6.2.3.7  Footnote 

Footnote  is  a  constituent  constraint  that  is  a  subdivision  of  a  Paragraph  and  is 
used  to  represent  footnotes  within  a  document. 

A  footnote  is  an  amount  of  content  that  is  logically  associated  with  a 
particular  part  of  the  document  body  but  which  is  intended  to  be  read  and  laid 
out  separately  from  its  associated  part  of  the  document.  Typically,  a  footnote 
consists  of  a  footnote  identifier,  which  is  embedded  within  the  document  body, 
and  the  footnote  itself,  which  is  laid  out  elsewhere. 

A  Footnote  is  a  composite  logical  constituent  whose  immediate  subordinates 
consist  of  the  constituent  constraint  FootnoteRef erence,  which  represents  the 
footnote  identifier,  followed  by  the  constituent  constraint  FootnoteBody,  which 
represents  the  footnote  itself.  Both  of  these  subordinates  are  mandatory. 
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6 . 2 . 3  o  @    F@9tBot@M@f  @r®sse@ 

FootnoteReference  is  a  constituent  constraint  that  is  used  to  represent  a 
footnote  reference  within  the  body  of  a  doeument. 

FootnoteReference  is  a  basic  logical  constituent  that  contains  a  content 
generator  which  when  evaluated  produces  a  character  string  which  constitutes  the 
footnote  reference  referred  to  above. 

The  generated  character  string  consists  of  a  ladsel  with  optional  prefix  and 
suffix  character  strings.  The  label  is  used  to  uniquely  identify  a  particular 
footnote  and  may  consist  of  a  number  which  is  represented  in  the  form  of  Arabic 
or  Roman  niimerals  or  by  an  alphabetic  equivalent.  The  number  may  be 
automatically  generated  so  that  its  value  is  incremented  for  each  successive 
footnote.  Alternatively,  the  label  may  consist  of  a  user  defined  character 
string. 

In  a  sequence  of  footnotes,  automatic  and  user  defined  labels  may  be  freely 
mixed  (giving  for  example  the  sequence  1,2*, 3, 4).     If  the  label  consists  of  a 
User-defined  character  string,  the  automatically  generated  number  sequence  is 
not  incremented. 

An  example  of  a  footnote  reference  ie  '(2)'  where         and         are  user  defined 
prefix  and  suffix  strings  respectively  and  '2'  is  the  automatically  generated 
label.  Another  example  is  'note^'  where  '5'  is  the  label  and  'note'  is  a  prefix 
string  which  also  contains  the  control  function  PLU  to  enable  the  label  to  be 
represented  in  the  form  of  a  superscript.     In  this  case,  a  suffix  string 
containing  the  control  function  PLD  would  be  required  to  cause  the 
super scripting  to  be  cancelled  before  the  following  text. 

The  format  of  the  content  generator  referred  to  above  is  described  in  6.6.8. 
6.2.3.9  FootnoteBody 

FootnoteBody  is  a  constituent  constraint  which  represents  the  content  of  a 
footnote . 

FootnoteBody  is  a  composite  logical  constituent  whose  subordinates  consist  of 
the  constituent  constraint  FootnoteNumber,  which  is  mandatory  and  represents  the 
footnote  identifier,  followed  by  a  sequence  of  one  or  more  constituent 
constraints  of  the  type  FootnoteText  which  represents  the  footnote  content.  The 
identifier  referred  to  above  is  identical  to  the  corresponding  footnote 
identifier  which  is  embedded  in  the  content  of  the  document  body  and  represented 
by  the  constituent  constraint  FootnoteReference. 

The  constituents  subordinate  to  FootnoteBody  are  intended  to  be  laid  out 
separately  from  the  other  parts  of  the  document  content.  When  a  generic  layout 
structure  is  specified  for  the  document,  these  constituents  axe  constrained  to 

be  laid  out  in  a  FootnoteArea  frame  (see  6.3.5.9). 
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6.2.3.10  FootnoteNumber 

FootnoteNumber  is  a  constituent  constraint  that  represents  the  footnote 
identifier  within  the  footnote  body. 

This  identifier  is  identical  to  the  content  associated  with  the  constituent 
constraint  FootnoteReference  but  is  intended  to  be  laid  out  so  that  it 
immediately  precedes  the  content  of  the  footnote  body. 

FootnoteNumber  is  a  basic  logical  constituent  that  contains  a  content  generator 
which  when  evaluated  produces  the  identifier  referenced  sdsove.  The  format  of 
this  content  generator  is  the  same  as  the  content  generator  that  may  be 
specified  for  the  constituent  constraint  FootnoteReference. 

It  is  required  to  specify  the  layout  category  name  'Footnote'  for  this 
constituent.    This  along  with  a  permitted  categories  attribute  of  'Footnote'  on 
the  footnote  frame  will  ensure  that  this  constituent  is  laid  out  in  a 
FootnoteArea  frame  when  generic  layout  structure  ie  specified  within  the 
document . 

6.2.3.11  FootnoteText 

FootnoteText  is  a  constituent  constraint  that  is  used  to  represent  the  footnote 
content.  It  is  the  lowest  logical  subdivision  of  a  FootnoteBody . 

FootnoteText  is  a  basic  logical  constituent  that  references  one  or  more  content 
portions  each  containing  processable^  formatted  or  formatted  processable 
character  content. 

It  is  required  to  specify  the  layout  category  name  'Footnote'  for  this 
constituent.    This  along  with  a  permitted  categories  attribute  of  'Footnote'  on 
the  footnote  frame  will  ensure  that  this  constituent  is  laid  out  in  a 
FootnoteArea  frame  when  generic  layout  structure  is  specified  within  the 
document . 

6.2.4    Common  content  part  of  the  logical  stzructure 
6.2.4.1  CommonContent 

Commoncontent  is  a  constituent  constraint  that  represents  common  content  that  is 
to  be  laid  out  in  the  header  and  footer  areas  of  the  pages  of  a  document.  Common 
content  consists  of  any  combination  of  character,  raster  graphics  and  geometric 
graphics  content. 
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Any  number       constituent  constraints  of  the  type  CommonContent  may  be  contained 
in  a  document.  CommonContent  is  a  composite  logical  object  class  whose  immediate 
subordinates  consist  of  an  arbitrary  ordered  sequence  of  one  or  more  of  the 
following  constituent  constraints: 

-  CommonText; 
PageNtimber; 

-  CommonRaster; 

-  CommonGeometric . 

When  the  generic  layout  structure  is  present,  constituents  of  the  type 
CommonContent  and  their  associated  subordinate  constituents  are  constrained  to 
be  laid  out  in  frames  representing  header  or  footer  areas  using  the  'logical 
source'  mechanism  (see  6.3.6). 

6.2.4.2  CommonText 

CommonText  is  a  constituent  constraint  that  represents  the  common  character 
content  that  is  to  be  laid  out  in  the  header  or  footer  area  of  a  dociiment.  For 
example,  header  or  footer  content  that  appears  on  each  page  in  a  sequence  of 
pages  may  be  represented  by  this  constituent. 

CommonText  is  a  basic  logical  object  class  that  references  one  or  more  content 
portions  each  containing    processable,  formatted  and  formatted  processzdsle 
ch2u:acter  content. 


6.2.4.3  PageNumber 

PaqeNumber  is  a  constituent  constraint  that  represents  the  common  character 
content  that  is  to  be  laid  out  in  the  header  or  footer  area  of  a  document.  This 
constituent  is  specifically  used  when  it  is  required  to  present  a  header  or 
footer  content  which  contains  an  automatically  generated  page  number. 

PageNumber  is  a  basic  logical  object  class  that  contains  a  content  generator. 
This  content  generator  contains  a  reference  to  a  page  number  which  is 
automatically  evaluated  when  the  docximent  is  laid  out.  This  provides  the  means 
of  representing  the  page  numbers  that  are  displayed  on  the  consecutive  pages  of 
a  document. 

Each  page  number  consists  of  a  single  number  which  may  be  represented  in  the 
form  of  Ar2J::ic  or  Roman  niimerals  or  in  its  alphabetic  equivalent.  Page  numbering 
schemes  may  start  at  0  or  any  value  greater  than  0. 

The  format  of  the  content  generators  is  defined  in  6.6.6. 
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6.2.4.4  CoimnonRaater 

commonRaater  is  a  constituent  constraint  that  represents  the  common  raster 
graphics  content  that  is  to  be  laid  out  in  the  header  or  footer  area  of  a 
document.  For  example,  this  constraint  may  be  used  to  represent  a  logo  which  is 
to  be  laid  out  on  each  page  of  a  document. 

Common  raster  is  a  basic  logical  object  class  which  references  a  single  content 
portion  containing  formatted  processable  raster  graphics  content. 

6.2.4.5  ComDonGeometric 

CommonGeometric  is  a  constituent  constraint  that  represents  the  common  geometric 
graphics  content  that  is  to  be  laid  out  in  the  header  or  footer  area  of  a 
document.  For  example,  this  constraint  may  be  used  to  represent  a  graphical  icon 
which  is  to  be  laid  out  on  each  page  of  a  document. 

Commongeometric  is  a  basic  logical  object  class  which  references  a  single 
content  portion  containing  formatted  processable  geometric  graphics  content. 

6.3    Layout  characteristics 

This  subclause  defines  the  layout  constituent  constraints  provided  by  this 
profile  to  represent  the  characteristics  of  documents. 

Different  constituent  constraints  may  be  used  to  represent  and  distinguish  peurts 
of  a  document  that  have  different  layout  characteristics.  This  subclause 
describes  the  general  characteristics  and  typical  uses  of  the  constituent 
constraints  that  are  provided. 

The  descriptions  of  the  layout  characteristics  represented  by  each  of  the 
constituent  constraints  is  provided  for  guidance  only.  It  is  the  responsibility 
of  the  user  to  determine  how  a  document  is  to  be  represented  using  the 
constituents  provided.  Adherence  to  these  guidelines  can  enhance  the  mutual 
understanding  of  a  document  by  an  originator  and  a  recipient. 

6.3.1    Overview  of  the  layout  characteristics 

The  document  structure  allows  the  document  content  to  be  laid  out  and  presented 
in  one  or  more  page  sets.  Each  page  set  may  be  used  for  different  parts  of  the 
document,  for  example,  the  title  page,  foreword,  table  of  contents,  document 
body  and  appendices. 

Each  page  set  consists  of  a  series  of  pages.  In  general,  each  page  may  be  sub- 
divided into  three  areas:  the  body  area,  which  is  used  to  layout  the  document 
body;  and  the  header  and  footer  areas,  which  may  be  used  to  layout  the  common 
content . 
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Four  page  layout  types  eure  supported  by  this  profile.  Each  page  layout  type 
specifies  how  the  body,  header  and  footer  areas  are  positioned  within  each  page 
and  how  the  content  nay  be  presented  within  each  of  those  areas.  These  four 
types  are  referred  to  as  page  layouts  A,  B,  C  and  D  and  are  illustrated  in 
figures  1,  2,  3  and  4  respectively. 

It  is  intended  that  all  applications  which  use  this  profile  ahall  support  page 
layout  A,  whereas  support  for  the  other  three  page  layouts  nay  be  specified  as 
optional . 

Page  layout  A  is  used  when  the  character  content  is  to  be  laid  out  horizontally 
(from  left  to  right  or  from  right  to  left)  and  from  top  to  bottom  within  the 
body  area.  This  layout  is  typically  used  for  documents  written  in  Latin  based, 
Hebrew  and  AreJsic  languages. 

Page  layout  B  is  used  when  the  character  content  is  to  be  laid  out  vertically 
(bottom  to  top  or  top  to  bottom)  and  from  left  to  right  within  the  body  area. 
This  layout  is  typically  used  for  documents  written  in  Latin  based,  Hebrew  and 
Arabic  languages  in  which  it  is  required  to  layout  the  content  in  landscape 
orientation  within  the  body  area  of  the  page. 

Page  layouts  C  and  D  are  used  when  the  chfuracter  content  is  to  be  laid  out 
vertically  and  from  right  to  left  within  the  body  area.  These  layouts  are 
typically  used  in  documents  written  in  languages  which  use  ideograms,  such  as 
Japanese  and  Chinese  characters. 

The  body  area  may  be  further  sub-divided  into  areas  composed  of  single  and 
multiple  columns  and  an  aurea  may  be  reserved  for  footnotes.  In  addition,  the 
header  and  footer  areas  may  be  sub-divided  to  allow  the  representation  of 
different  content  types. 

6.3.2  DocumentLayoutRoot 

DocximentLayoutRoot  is  a  constituent  constraint  that  represents  the  top  level  in 
the  document  layout  structure.  Its  immediate  subordinates  consist  of  a  sequence 
of  one  or  more  constituents  of  the  type  PageSet.  The  numbering  schemes  for  pages 
may  be  initialised  on  this  constituent  constraint. 

6.3.3  PageSet 

PageSet  is  a  constituent  constraint  that  represents  a  grouping  of  pages  within  a 
document.  A  PageSet  is  typically  used  to  represent  a  part  of  a  document  that  has 
different  layout  requirements  from  other  parts  of  a  document.  Also,  a  PageSet 
may  correspond  to  a  part  of  a  document  that  has  a  certain  logical  significance, 
for  example,  a  PageSet  might  represent  the  front  matter  in  a  document  or  an 
individual  chapter. 
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Only  one  level  of  PageSet  is  allowed  in  a  document.  However,  a  document  may 
contain  any  number  of  class  definitions  of  the  type  PageSet  which  may  be  used, 
for  example,  to  provide  a  choice  of  alternative  layouts  for  different  parts  of  a 
document  or  to  specify  the  exact  layout  requirements  for  each  successive  part  of 
a  document. 

The  immediate  subordinates  of  a  PageSet  consist  of  a  combination  of  constituent 
constraints  of  the  types  Page,  RectoPage  and  VersoPage,  as  described  in  6.3.4.1. 

6.3.4    Page  characteristics 
6.3.4.1    Page  constituents 

Three  constituent  constraints  are  provided  to  represent  the  pages  within  a 
document,  namely  Page,  RectoPage  and  VersoPage. 

The  only  difference  in  the  characteristics  of  these  types  of  constituent 
constraints  concerns  the  values  that  may  be  specified  for  the  parameter  "side  of 
sheet"  in  the  attribute  "medium  type".  In  the  case  of  Page,  the  value  of  this 
parameter  may  be  specified  as  'recto',   'verso'  or  'unspecified'.  In  the  case  of 
RectoPage,  the  value  of  this  parameter  may  be  specified  as  'recto'  or 
'unspecified';  in  the  case  of  VersoPage,  the  value  of  this  parameter  may  be 
specified  as  'verso'  or  'unspecified'.    The  values  "recto"  and  "verso"  of  the 
"side  of  sheet"  parameter  of  the  "medium  type"  attribute  are  non-basic. 

The  pages  that  make  up  a  page  set  consist  of  an  optional  initial  page  which  is 
represented  by  the  constituent  constraint  Page  and  which  is  optionally  followed 
by  either: 

a)  A  sequence  of  pages  represented  by  the  constituent  constraint  Page. 
All  pages  in  this  sequence  shall  have  the  same  layout  characteristics 
(see  note)  but  these  characteristics  may  differ  from  those  of  the 
initial  page. 

b)  A  sequence  of  pages  which  are  intended  to  be  laid  out  alternatively 
on  the  'recto'  and  'verso'   (or  on  the  'verso'  and  'recto')  sides  of 
the  presentation  medium  and  eure  represented  by  the  constituent 
constraints  RectoPage  aind  VersoPage  respectively.  All  pages  in  this 
sequence  shall  have  the  Seone  layout  characteristics  (see  note)  but 
these  characteristics  may  differ  from  those  of  the  initial  page. 

Pages  having  the  same  layout  cheuracteristics  are  pages  that  have  the  same  page 
layout  (see  6.3.4.5)  and  for  which  the  body  area,  header  area  (if  present)  and 
footer  area  (if  present)  have  the  same  dimensions  and  positions  within  the  page 
(see  6.3.4.3).     Pages  having  the  same  layout  cheLracteristics  do  not  necessarily 
have  the  same  position  on  the  presentation  medium  (see  6.3.4.4). 

A  page  set  shall  contain  at  least  one  page. 

An  initial  page  is  typically  used  at  the  beginning  of  a  document  or  of  a  section 
within  a  document.  It  may  be  used,  for  example,  for  a  title  page  whose  layout 
requirements  differ  from  the  following  pages. 
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Tha  following  restrictions  also  apply  to  the  pages  within  a  page  set: 

i)  all  the  pages  shall  have  the  sane  dimensions  and  orientation  (see 
6.3.4.2); 

ii)  all  pages  are  to  be  laid  out  on  the  same  size  of  presentation  medium 
( see  6.3.4.3). 


6.3.4.2    Page  diaansions 

The  dimensions  of  the  pages  may  be  specified  as  any  value  (in  BMUs)  that  is 
equivalent  to  or  less  than  ISO  A3  or  ANSI  B  paper  sizes  in  portrait  or  landscape 
orientation.  The  dimensions  may  be  specified  in  portrait  or  landscape 
orientation.    Japanese  page  sizes  B4  and  B5  are  also  supported  but  the 
dimensions  of  these  pages  lie  within  the  range  of  dimensions  given  above. 

Dimensions  equivalent  to  or  less  than  the  common  assure^d  reproduction  area  of 
ISO  A4  and  ANSI-A  in  portrait  or  landscape  orientation  are  basic  values.  Larger 
page  sizes  are  non-basic  and  their  use  shall  be  indicated  in  the  document 
profile . 

Any  default  page  dimensions  may  be  specified  in  the  document  profile  subject  to 
the  maximum  dimensions  defined  above. 


NOTE  -  The  size  termed  "North  American  Letter  (NAL)**  in  ISO  8613  (e.g.  in 
ISO  8613-2,  clause  7)  is  in  this  specification  called  "ANSI  A"  in  order  to 
be  consistent  with  the  other  reference  to  ANSI  standard  paper  sizes. 


6.3.4.3    Nominal  page  sizes 

The  nominal  page  sizes  that  may  be  specified  are  listed  in  table  1.  These  may  be 
specified  in  portrait  or  landscape  orientation.  All  values  of  nominal  page  size 
are  non-basic  and  hence  all  values  used  in  a  document  shall  be  indicated  in  the 
document  profile. 

Any  value  of  nominal  page  size  defined  in  table  1,  subject  to  the  restrictions 
specified  above,  may  be  specified  as  the  default  value  in  the  document  profile. 

Teible  1  also  includes  the  recommended  assured  reproduction  area  (ARA) . 
Information  loss  may  occur  when  a  document  is  reproduced  if  the  dimensions  of 
constituent  constraints  of  the  type  page  exceed  the  ARA  for  the  specified 
nominal  page  size. 
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Page  type 

Size  in  inches 
or  millimetres 

Size 

in  BMUs 

ARA  in  BMUS 

ISO  AS 

148mm  x  210mm 

7 

015 

X 

9 

920 

not  defined 

ISO  A4 

210mm  X  297mm 

9 

920 

X 

14 

030 

9  240  X  13  200 

ISO  A3 

297mm  x  420mm 

14 

030 

X 

19 

840 

13  200  X  18  480 

ANSI  legal 

8. Sin.  X  14in. 

10 

200 

X 

16 

800 

9  240  X  15  480 

ANSI  A 

8. Sin.  X  llin. 

10 

200 

X 

13 

200 

9  240  X  12  400 

ANSI  B 

llin.    X  17in 

13 

200 

X 

20 

400 

12  744  X  19  656 

Japan-legal 

257mm    x  364mm 

12 

141 

X 

17 

196 

11  200  X  15  300 

Japan-letter 

182mm    x  257mm 

8 

598 

X 

12 

141 

7  600  X  10  200 

€.3.4.4    Page  offset 

The  page  offset  is  the  distance  of  the  position  of  the  left  and  top  edges  of  the 
page  relative  to  the  left  and  top  edges  respectively  of  the  presentation  medium 
on  which  each  page  is  reproduced.  Any  value  of  page  offset  may  be  specified 
provided  that  no  part,  of  the  page  area  lies  outside  the  area  of  the  nominal 
page.  Also,  page  offsets  specified  for  the  initial,  recto  and  verso  pages  within 
a  given  page  set  nay  differ.  The  default  page  offset  may  be  specified  in  the 
document  profile. 

€.3.4.5    Page  layout  characteristics 


€.3.4.5.1    General  characteristics 

Each  page  in  a  docmnent  may  be  subdivided  into  three  rectangular  eureas,  as 
follows : 

a  body  area  which  is  reserved  for  content  that  belongs  to  the  body 
part  of  the  document  ( see  6.3.5); 

a  header  area  which  is  reserved  for  common  header  content  (see 
6.3.6); 

-         a  footer  area  which  is  reserved  for  common  footer  content  (see 
6.3.6). 

The  body  area  is  mandatory  and  shall  occur  on  every  page  in  a  docximent.  The 
header  and  footer  areas  are  both  optional. 

Also,  these  three  aireas  shall  be  entirely  contained  within  the  page  area  and 
shall  not  overlap. 

Four  types  of  page  layout  are  supported  as  defined  below. 
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6.3.4.5.2    Page  layout  A 

For  page  layout  A  the  header  and  footer  areas  are  placed  above  and  below  the 
body  area  respectively.  The  layout  paths  in  the  header,  body  and  footer  areas 
are  specified  as  270  degrees.  This  type  of  layout  is  illustrated  in  figure  1. 


6.3.4.5.3  Page  layout  B 

For  page  layout  B  the  header  and  footer  areas  are  placed  above  and  below  the 
body  area  respectively.  The  layout  path  in  the  body  area  is  specified  as  0 
degrees;  in  the  header  and  footer  areas  the  layout  paths  are  specified  as  270 
degrees.  This  type  of  layout  is  illustrated  in  figure  2. 

6.3.4.5.4  Page  layout  C 

For  page  layout  C  the  header  and  footer  areas  are  placed  above  and  below  the 
body  area  respectively.  The  layout  path  in  the  body  area  is  specified  as  180 
Hegrees;  in  the  header  and  footer  areas,  the  layout  paths  are  specified  as  270 
degrees.  This  type  of  layout  is  illustrated  in  figure  3. 

6.3.4.5.5  Page  layout  D 

For  page  layout  D  the  header  and  footer  areas  are  placed  to  the  right  and  left 
of  the  body  eirea  respectively.  The  layout  paths  in  the  header,  body  and  footer 
areas  are  all  specified  as  180  degrees.  This  type  of  layout  is  illustrated  in 
figure  4. 
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Figure  1  -  Page  layout  type  A 


Figure  2  -  Page  layout  type  B 
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Plgnr*  3  -  Page  layont  type  C 


Figure  4  -  Page  layout  type  D 
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6.3.5    Body  area  characteris-ticB 

6.3.5.1  General  characteriatica 

The  body  area  is  the  area  within  a  page  where  the  main  matter  of  the  document, 
that  is  the  'body  part  of  the  document,  is  laid  out. 

The  body  area  may  consist  of  a  single  frame  into  which  the  content  is  directly 
laid  out.  In  this  case,  the  body  area  is  represented  by  a  BasicBody  frame. 

Alternatively,  the  body  area  is  subdivided  into  different  rectangular  regions  to 
provide  for  combinations  of  single  or  multiple  column  layout  and  the  layout  of 
footnotes.  In  this  case,  the  body  frame  is  represented  by  a 
Vari2J3leCompositeBody  frame. 

6.3.5.2  BasicBody 

BasicBody  is  a  constituent  constraint  which  defines  a  l,owest  level  frame  into 
which  content  is  directly  laid  out. 

The  position  and  dimensions  of  this  frame  are  fixed.  The  layout  path  specified 
depends  upon  the  page  layout  type  being  used  (see  6.3.4.5). 

6.3.5.3  VariableCon^xssiteBody 

VeuriableCompositeBody  is  a  constituent  constraint  that  defines  a  composite  frame 
which  contains  one  or  more  subordinate  variably  positioned  frames.  A 
VariableCompositeBody  frame  has  a  fixed  position  and  fixed  dimensions.  The 
layout  path  specified  for  this  frame  depends  upon  the  page  layout  type  being 
used  (see  6.3.4.5). 

The  immediate  subordinates  of  frames  of  this  type  consist  of  an  arbitrary 
ordered  sequence  of  one  or  more  frames  of  the  following  constituent  constraints : 

-  BasicFloat; 

-  SnakingColumns ; 

-  SynchronizedColumns 

It  may  also  contain  a  single  frame  of  the  type  FootnoteArea . 

The  subordinate  frames  are  all  variably  positioned  and  have  variable  dimensions. 
Thus  the  relative  positions  of  these  frames  in  the  body  area  may  vary  and  depend 
upon  the  positions  of  other  frames  (if  any)  that  are  placed  in  the  same 
VariableCompositeBody  frame. 

The  layout  path  for  VariadaleCompositeBody  frames  may  be  specified  as  270,  0  or 
180  degrees.     This  determines  the  page  layout  type  used  in  the  case  where 
VarialbeCompositeBody  represents  the  entire  body  area. 
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Frames  of  the  type  BasicFloat,  SnakingColumna  and  SynchronizedColumns  are  laid 
out  along  the  layout  path  specified  (in  'normal'  positioning  fill  order). 
FootnoteArea  frames  are  laid  out  in  the  same  direction  as  the  body  area  layout 
path,  but  reverse  fill  order  is  used. 

These  frames  are  constrained  to  have  the  same  path  as  the  VariableCompositeBody 
frame  to  which  they  are  subordinate.    Except  for  frames  of  the  type 
SnakingColumns . 

Figures  5,  6  and  7  provide  illustrations  of  the  layout  of  frames  within  a 
VariableCompositeBody  frame  for  the  various  page  layout  types. 

A  choice  of  subordinate  frames  of  the  types  listed  above  may  be  specified  for  a 
VariableCompositeBody  frame.  Different  frame  types  may  be  selected  using  vetrious 
layout  directives  (see  6.4)  and  hence  the  layout  characteristics  of  the  body 
aireas  within  a  page  set  may  change  from  page  to  page  within  a  page  set. 

Figure  5  ~  Example  of  body  area  layout  for 
page  layout  A 
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Pigure  7  -  Bza^le  of  body  area  layoat  for 
page  layouts  c  and  d 
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6.3.5.4  Bas  icFloat: 

BaaicFloat  is  a  constituent  constraint  that  defines  a  lowest  level  frzune  that  is 
used  to  represent  a  single  column  area  within  a  body  area.  A  single  column  area 
is  typically  used  to  layout  content  in  the  form  of  a  single  column.  This  is  a 
variably  positioned  frame. 

The  dimension  of  this  frame  in  the  direction  orthogonal  to  the  layout  path  of 
the  body  area  is  fixed  or  defaults  to  the  maximum  value  allowed  within  the  body 
area. 

The  dimensions  of  this  frame  in  the  direction  parallel  to  the  layout  path  of  the 
body  area  is  specified  as  'Rule-B'.  This  dimension  is  therefore  automatically 
adjusted  during  the  layout  process  to  be  the  minimum  required  to  contain  all  the 
content  allocated  to  the  frame. 

The  layout  path  specified  for  this  frame  is  the  same  as  that  specified  for  the 
body  area.  Content  may  only  be  laid  out  in  this  frame  in  the  direction  of  the 
layout  path  specified. 

6.3.5.5  SnakingColumns 

SnakingColumns  is  a  constituent  constraint  that  defines  a  composite  frame  that 
represents  a  snaking  column  area  within  a  body  area.  A  snaking  column  area  is 
typically  used  for  the  layout  of  one  or  more  columns  of  content  in  which  the 
content  is  allowed  to  flow  freely  from  one  column  to  the  next. 

This  frame  is  variably  positioned.  Its  immediate  subordinates  consist  of  one  or 
more  frames  of  the  type  ColumnVariable .  Examples  of  the  layout  of  SnakingColumns 
frames  are  given  in  figure  8. 

The  dimension  <>f  a  ^snakingCoIumns  frame  in  the  direction  orthogonal  to  the 
layout  path  of  the  body  area  is  fixed  or  defaults  to  the  maximum  value  allowed 
within  the  body  area. 

The  dimensions  of  this  frame  in  the  direction  parallel  to  the  layout  path  of  the 
body  area  is  specified  as  'Rule-B'.  This  dimension  is  therefore  automatically 
adjusted  to  accommodate  the  subordinate  frames  which  ctre  laid  out  in  it. 

The  layout  path  for  a  SnakingColumns  frame  may  be  specified  as  0  or  180  degrees 
in  the  case  of  page  layout  A,  90  or  270  degrees  in  the  case  of  page  layout  B, 
and  270  degrees  in  the  cases  of  page  layouts  C  emd  D. 

The  attribute  "balance"  may  be  specified  for  a  SnakingColumns  frame  to  indicate 
that  two  or  more  of  the  subordinate  ColumnVariable  frames  are  to  be 
approximately  equal  in  length  in  the  vertical  dimension  in  the  case  of  page 
layout  A  and  are  to  be  approximately  equal  in  length  in  the  horizontal  dimension 
in  the  cases  of  page  layouts  B,  C  and  D  (see  note).    Note  that  "approximately 
equal"  in  the  context  of  the  "balance"  attribute  means  that  the  leading  edges  of 
the  layout  objects  being  balanced  are  aligned,  as  closely  as  possible,  to  a  line 
orthogonal  to  the  layout  path  for  the  objects. 

NOTE  -  The  attribute  "balance"  may  be  ignored  when  the  subordinate 
ColumnVariable  frsunes  have  unec[ual  widths. 
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Figure  8  -  Ezas^lea  of  the  layout  of  snalcing  columna 
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6.3.5.6  SynchroaizedColumns 

SynchronizedColumns  is  a  constituent  constraint  that  defines  a  composite  frame 
that  represents  a  synchronized  columns  £u:ea  within  a  body  area.  A  synchronized 
columns  area  is  typically  used  to  represent  one  or  more  columns  of  content  such 
that  the  content  laid  out  in  each  column  belongs  to  different  layout  streams. 
Thus  content  laid  out  in  one  column  is  not  allowed  to  flow  into  the  next  column. 

This  type  of  column  layout  is  typically  used  when  it  is  required  to  layout 
separate  amounts  of  content  in  parallel  with  one  another  such  that  they  are 
aligned.  Examples  are  the  synchronized  layout  of  content  belonging  to  different 
languages  and  the  layout  of  a  figure  in  peirallel  with  some  text.  An  example  is 
shown  in  figure  9. 

With  regard  to  positioning  and  dimensioning,  SynchronizedColumns  frames  have  the 
same  characteristics  as  SnakingColumns  freunes. 

The  immediate  subordinates  of  a  SynchronizedColumns  frame  consist  of  any  number 
of  frames  of  the  type  ColumnFixed. 

The  layout  path  for  a  SynchronizedColumns  frame  is  270  degrees  for    page  layout 
A,  0  degrees  for  page  layout  B  and  180  degrees  for  page  layouts  C  and  D. 


Figure  9  -  Exanple  of  synchronized  column  layout 
for  page  layout  A 
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6.3.5.7  ColumnVariable 

ColmnnVariable  is  a  constituent  constraint  that  defines  a  lowest  level  frame 
that  is  used  to  represents  a  column  of  content  within  a  snakingColumns  frame. 
This  is  a  frame  which  is  variably  positioned. 

The  dimension  of  this  frame  in  the  direction  puallel  to  the  layout  path  of  the 
superior  SnakingColumns  frame  (that  is,  the  column  width)  is  fixed.  The 
dimensions  of  different  instances  of  ColumnVariable  frames  within  a  given 
Snakingcoliunns  frame  may  differ  to  allow  columns  of  different  widths  to  be 
specified. 

The  dimension  in  the  direction  orthogonal  to  the  layout  path  of  the  superior 
frame  (that  is,  the  column  length)  may  be  specified  as  'Rule-B'  or  'maximum- 
size'. 

The  layout  path  for  ColumnVariable  frames  is  270  degrees  in  the  case  of  page 
layout  A,  0  degrees  in  page  layout  B  and  180  degrees  in  page  layouts  C  and  D. 

All  ColumnVariable  frames  subordinate  to  the  same  SnakingColumns  frame  shall 
have  the  same  category  name;  different  names  may  be  used  for  ColiimnVariable 
frames  laid  out  in  different  SnakingColumns  frames. 

6.3.5.8  ColumnFixed 

ColumnFixed  is  a  constituent  constraint  that  defines  a  lowest  level  frame  that 
is  used  to  represent  a  column  of  content  within  a  SynchronizedColumns  frame. 
This  is  a  frame  which  has  a  fixed  position. 

The  dimension  of  this  frame  in  the  direction  orthogonal  to  the  layout  path  of 
the  superior  SynchronizedColumns  frame  (that  is,  the  column  width)  may  be  fixed 
or  specified  as  'maximum  size'  (see  note)  in  all  page  layout  types.  This 
dimension  may  differ  for  different  instances  of  ColuinnFixed  frames  within  a 
given  SynchronizedColumns  frame  to  allow  columns  of  different  widths  to  be 
specified.  However,  the  widths  shall  be  specified  such  that  the  columns  do  not 
overlap. 

The  dimension  of  this  frame  in  the  direction  parallel  to  the  layout  path  of  the 
superior  frame  (that  is,  the  column  length)  may  be  specified  as  'Rule-B'  or 
'maximum-size'  in  the  cases  of  page  layouts  A  and  B.  In  the  cases  of  page 
layouts  C  and  D,  this  dimension  may  only  be  specified  as  'maximum-size'. 

The  ColumnFixed  frames  subordinate  to  a  given  SynchronizedColumns  frame  shall 
have  different  category  names. 

The  layout  path  for  ColumnFixed  frames  shall  be  equal  to  the  layout  path  of  the 
superior  SynchronizedColumns  frame. 

The  content  laid  out  in  different  ColumnFixed  frames  within  the  same 
SynchronizedCol\imns  frame  may  be  specified  as  'synchronized'  by  using  the 
attribute  "synchronization". 
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NOTE  -  The  value  'mztximum  size'  may  only  be  specified  for  the  right  most 
ColumnFixed  frames  (relative  to  the  page  co-ordinate  system)  laid  out  in  a 
SynchronizedColumns  frame,  to  prevent  overlapping  of  the  frames. 

6.3.5.9  FootnoteArea 

Foot note Are  a  is  a  constituent  constraint  that  defines  a  lowest  level  frame  that 
is  used  to  reprissent  a  footnote  area  within  a  body  area.  A  footnote  area  is 
typically  used  for  the  layout  of  footnotes. 

Frames  of  this  type  are  variably  positioned  with  a  positioning  fill  order 
specified  as  'reverse'.  Hence  this  frame  is  positioned  adjacent  to  the  leading 
edge  of  the  VariablecompositeBody  frame. 

The  dimension  of  FootnoteArea  frames  in  the  direction  orthogonal  to  the  layout 
path  of  its  superior  frame  is  fixed  or  specified  as  'maximum  size'.  In  the 
direction  of  the  layout  path,  the  dimension  is  specified  by  'Rule-B'  which  means 
that  this  dimension  is  automatically  adjusted  to  contain  all  the  content  that  is 
allocated  to  it. 

The  layout  path  for  FootnoteArea  frames  is  the  seune  as  that  specified  for  the 
body  area. 

The  content  that  nay  be  laid  out  in  this  frame  is  limited  to  the  content  that  is 
associated  with  basic  logical  objects  which  are  subordinates  of  the  composite 
logical  object  ' FootnoteBody ' .    To  achieve  this,  the  permitted  categories 
attribute  of  this  frame  shall  specify  the  category  'Footnote',  the  same  name 
required  on  the  basic  logical  objects  for  footnotes  (see  6.2.3.10  and  6.2.3.11). 

6.3.6    Header  and  footer  area  chauracteristics 

6.3.6.1    General  characteristics 

The  header  and  footer  aureas  consist  of  either  basic  areas  or  composite  areas. 

A  basic  header  or  footer  area  is  an  area  into  which  the  content  is  directly  laid 
out.  This  type  of  area  is  represented  by  a  constituent  constraint  of  the  type 
BasicHeader  or  BasicFooter  respectively. 

A  composite  header  or  footer  area  is  an  area  which  is  subdivided  into  separate 
sourced  content  and  arranged  content  areas  to  provide  greater  versatility  with 
regard  to  the  layout  of  the  content.    This  type  of  area  is  represented  by  a 
constituent  constraint  of  the  type  CompositeHeader  or  Compos it eFooter 
respectively. 

In  the  case  of  basic  header  or  footer  areas,  the  content  allocated  to  these 
areas  is  derived  from  the  common  part  of  the  logical  structure  of  a  document.  In 
the  case  of  composite  header  or  footer  areas,  the  content  may  again  be  derived 
from  the  common  part  of  the  logical  structure  of  a  document  but  the  content  may 
also  be  derived  from  common  content  specified  in  the  generic  layout  structure. 
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6.3.6.2  BasicHeader  and  BasicFooter 

BasicHeader  and  Basic  Footer  are  constituent  constraints  that  define  lowest 
level  frames  that  represent  areas  within  a  page  that  are  reserved  for  common 
content . 

These  types  of  frame  have  fixed  positions  and  dimensions.  The  positioning  of 
these  frames  within  a  page  and  the  layout  paths  that  may  be  specified  for  them 
depends  upon  the  page  layout  type  used  ( see  6.3.4.5) 

The  content  that  is  laid  out  in  these  frames  is  derived,  using  the  logical 
source  mechanism,  from  the  content  associated  with  the  composite  logical  object 
classes  of  the  type  CommonContent . 

6.3.6.3  Coii^KJsiteHeader  and  Coii^>oaiteFooter 

CompositeHeader  and  Compos iteFooter  are  constituent  constraints  that  define 
composite  frames  that  represent  areas  within  a  page  that  are  reserved  for  common 
content. 

These  types  of  frame  have  fixed  positions  and  dimensions.  The  positioning  of 
these  frames  within  a  page  and  the  layout  path  that  may  be  specified  for  them 
depends  upon  the  page  layout  type  used  ( see  6.3.4.5) 

The  subordinates  of  these  frames  may  consist  of  either: 

a)  any  number  and  combination  of  variably  positioned  frames  of  the  types 
SourcedContentVariable  and  ArrangedContentVari2d3le . 

or 

b)  any  nvimber  and  combination  of  fixed  positioned  frames  of  the  types 
SourcedContentFixed  and  ArrangedContentFixed. 

In  case  b),  the  subordinate  frames  may  overlap  without  restriction. 


6.3.6.4  SourcedContentVariable 

A  SourcedContentVariable  frame  is  a  constituent  constraint  that  defines  a  lowest 
level  frame  that  represents  a  region  within  a  header  footer  area  that  contains 
common  content  derived  from  the  generic  logical  structure.  This  frame  is 
variably  positioned  and  its  layout  path  is  the  same  as  that  of  the  containing 
header  or  footer  area. 

The  dimension  of  this  frame  in  the  direction  orthogonal  to  the  layout  path  of 
the  superior  frame  is  fixed  or  specified  as  ' maximum- s i ze ' .    The  dimensions  of 
the  frame  in  the  direction  parallel  to  the  layout  path  of  the  superior  frame  is 
specified  as  either  fixed  or  'Rule-B'. 
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This  frame  is  required  to  specify  the  attribute  "logical  source*  which  indicates 
the  particular  instance  of  the  constituent  constraint  CommonContent  which 
contains  the  content  to  be  laid  out  in  this  frame. 

Typically,  this  frame  is  used  for  the  positioning  of  content  which  is  generated 
during  the  layout  process,  such  as  a  character  sequence  containing  a  page 
nximber. 


6.3.6.5  ArrangedContentVariable 

An  ArrangedContentVairiable  frame  is  a  constituent  constraint  that  defines  a 
lowest  level  frame  that  represents  a  region  within  a  header  or  footer  area  that 
contains  pre-defined  common  content  contained  in  the  generic  layout  structure. 
This  frame  is  variably  positioned  and  its  dimensions  axe  fixed. 

This  frame  references  one  or  more  blocks  of  type  GenericBlock  ( see  6.3.7)  which 
contain  the  content  to  be  laid  out  in  this  frame.  Thus,  this  frame  is  typically 
used  when  it  is  required  to  layout  pre-determined  common  content. 

6.3.6.6  SourcedContentFixed 

A  SourcedContentFixed  frame  is  a  constituent  constraint  that  defines  a  lowest 
level  frame  that  represents  a  region  within  a  header  footer  area,  that  contains 
common  content  derived  from  the  generic  logical  structure.  This  frame  has  a 
fixed  position  and  dimensions  and  its  layout  path  is  equal  to  that  of  the 
containing  header  or  footer  area. 

This  frame  is  required  to  specify  the  attribute  "logical  source"  which  indicates 
the  peurticuleo:  instance  of  the  constituent  constraint  CommonContent  which 
contains  the  content  to  be  laid  out  in  this  frame. 

Thus,  as  in  the  case  of  SourcedContentVariable  frames,  this  frame  is  used  for 
the  positioning  of  content  which  is  generated  during  the  layout  process,  such  as 
a  character  sequence  containing  a  page  number. 

6.3.6.7  ArrangedContentFixed 

An  ArrangedContentFixed  frame  is  a  constituent  constraint  that  defines  a  lowest 
level  frame  that  represents  a  region  within  a  header  or  footer  area  that 
contains  pre-defined  common  content  derived  from  the  generic  layout  structure. 
The  position  and  dimensions  of  this  frame  are  fixed.    This  frame  references  one 
or  blocks  of  type  GenericBlock  ( see  6.3.7)  which  contain  the  content  to  be  laid 
out  in  this  frame.  Thus  this  frame  is  typically  used  when  it  is  required  to 
layout  common  content  at  pre-determined  positions  in  the  header  or  footer  areas. 


35 


F0026  Part  1  -  Document  Application  Profile 


July  1992 


6.3.7    GenericBloclc  and  Specif icBlock 

Two  types  of  constituent  constraints  of  the  type  'block'  are  defined,  nanely 
GenericBlock  and  specif icBlock. 

Object  classes  of  the  type  GenericBlock  aay  occur  in  the  generic  layout 
structure  referenced  by  the  "generator  for  subordinates"  of  object  classes  of 
the  types  ArrangedContentvariable  and  ArrangedContentFixed.  When  the  layout 
process  is  performed  to  produce  a  document  in  formatted  processable  form, 
equivalent  blocks  may  occur  in  the  specific  layout  structure,  objects  of  this 
type  are  restricted  to  occur  within  the  header  and  footer  areas  of  the  page. 

Objects  of  the  type  SpecificBlock  may  only  occur  in  the  specific  layout 
structure.  They  are  created  during  the  document  layout  process  and  result  from 
the  layout  of  basic  logical  objects  into  lowest  level  frames  that  constitute  the 
body,  header  and  footer  areas. 


6.4    Document  layout  characteristics 

^  * 

Mechanisms  for  controlling  the  allocation  of  logical  constituents  to  various 
areas  in  the  layout  structure  are  defined  in  6.4.1.  Mechanisms  for  controlling 
the  layout  of  the  content  within  the  allocated  areas  are  defined  in  6.4.2. 

These  mechanisms  relate  to  docvunents  for  which  a  generic  layout  structure  is 
specified,  when  a  generic  layout  structure  is  not  present,  then  these  mechanisms 
are  restricted  as  described  in  6.4.3. 


6.4.1    Flow  controls 

Veurious  mechanisms  are  provided  to  control  the  allocation  of  constituent 
constraints  representing  the  'body  parts  of  the  logical  structure  of  a  document 
to  pages  sets,  pages  and  body  areas.  These  are  described  in  6.4.1.1,  6.4.1.2  and 
6.4.1.3.  The  mechanisms  for  controlling  the  layout  of  the  'common'  parts  of  a 
document  are  described  in  6.4.1.4. 


6.4.1.1    Allocation  of  content  to  page  sets 

Two  methods  of  allocating  the  constituent  constraints  associated  with  the  'body' 
part  of  the  document  to  page  sets  are  provided: 

a)  Layout  in  a  nominated  page  set; 

b)  starting  a  new  page  set. 

The  first  method  provides  the  ability  to  specify  that  a  part  of  a  document  is  to 
be  laid  out  entirely  within  a  specified  page  set.  This  may  be  specified  for 
constituent  constraints  of  the  types  Passage,  NumberedSegment  and  Paragraph 
using  the  attribute  "layout  object  class"  which  specifies  the  object  class 
identifier  of  the  required  class  of  page  set. 
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The  second  method  provides  the  ability  to  specify  that  the  logical  objects 
derived  from  a  particular  logical  constituent  constraint  in  a  dociiment  and  all 
subsequent  parts  of  a  document  are  to  be  laid  out  steurting  at  the  beginning  of  a 
new  page  set.  This  may  be  specified  for  the  following  logical  constituent 
constraints : 

-  Passage; 

-  NumberedSegment; 

-  Paragraph; 

-  Number; 

-  Body Text; 

-  BodyRaster;  , 

-  BodyGeometric . 

This  is  achieved  using  the  attribute  "new  layout  object"  which  specifies  the 
object  class  identifier  of  the  required  class  of  page  set. 

6.4.1.2    Page  breaks 

This  provides  the  ability  to  specify  that  the  logical  objects  derived  from  a 
particular  logical  constituent  constraint  in  a  docximent  and  all  subsequent  parts 
of  a  document  are  to  be  laid  out  steurting  at  the  beginning  of  a  new  page.  The 
page  specified  shall  belong  to  the  page  set  in  which  the  logical  objects  from 
the  immediately  preceding  logical  constituent  constraint  is  laid  out  (see  note). 

This  may  be  specified  for  the  following  logical  constituent  constraints: 

-  Passage; 

-  NumberedSegment; 

-  Paragraph; 

-  Number; 

-  BodyText; 

-  BodyRaster; 

-  BodyGeometric. 
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This  is  achieved  using  the  attribute  "new  layout  object" .  This  attribute  may 
specify  the  value  'page'  indicating  that  the  logical  constituent  constraint  is 
to  be  laid  out  steirting  on  the  next  available  page  which  may  be  of  any  class. 
Alternatively,  the  attribute  may  specify  that  the  logical  constituent  constraint 
is  to  be  laid  out  starting  on  a  page  of  a  particular  class;  this  is  achieved  by 
specifying  the  object  class  identifier  of  the  required  page  class. 

NOTE  -  The  specification  of  a  page  break  shall  not  be  used  to  layout  part 
of  a  document  in  a  new  page  set.  If  a  new  page  set  is  required,  then  this 
shall  be  explicitly  specified  as  described  in  6.4.1.1. 

€«4.1.3    Allocation  of  content  to  body  areas 

If  the  page  to  which  the  content  is  allocated  contains  a  basic  body  area,  then 
the  content  is  laid  out  in  sequential  order  in  that  body  area  in  the  form  of  a 
single  column. 

If  the  page  contains  a  composite  body  area,  then  the  content  is  allocated  to 
single,  snaking  and  synchronized  columns  areas  and  footnote  areas  as  described 
below. 


6.4.1.3.1    Layout  of  content  into  column  areas 

When  laying  out  content  into  a  composite  body  area  having  more  than  one 
subordinate  frame  class  (excluding  FootnoteArea  frame  classes),  it  is  necessary 

to  indicate  which  of  the  column  areas  is  to  be  used. 

Logical  objects  of  the  types  Paragraph,  Number,  FootnoteReference,  BodyText, 
BodyRaster  and  BodyGeometric  may  be  specified  to  be  laid  out  in  instances  of  one 
or  more  single  columns  area,  snaking  columns  area  or  synchronized  columns  area. 
This  is  done  by  giving  each  such  basic  logical  component  a  value  of  the 
attribute  'lay out -category'  which  corresponds  to  the  value  of  the  attribute 
'permitted-categories '  which  applies  to  the  lowest  level  of  frame  in  which  the 
content  is  to  be  laid  out. 

Note  that  any  basic  logical  objects  in  the  specific  logical  structure  to  which 
this  attribute  does  not  apply  will  be  laid  out  only  in  a  lowest  level  frame 
which  has  the  implicit  value  of  the  attribute  'permitted-categories'. 

The  use  of  layout  categories  ensures  that  if  there  is  insufficient  area  on  one 
page  to  lay  out  all  of  the  content  allocated  to  a  particular  type  of  area,  then 
the  laying  out  of  the  content  will  automatically  continue  in  the  same  type  of 
area  in  a  succeeding  page.  Thus  content  is  allowed  to  flow  freely  from  one  page 
to  the  next  when  the  type  of  layout  used  at  the  end  of  one  page  is  the  same  as 
that  at  the  beginning  of  the  succeeding  page. 
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It  is  necessary  to  ensure  the  correct  use  of  the  mechanism  for  the  layout  of 
ihdependent  layout  streams.     In  the  absence  of  additional  layout  directives, 
content  may  be  placed  in  available  space  within  an  earlier  frame  of  the 
specified  'permitted-categories ' .     If  this  is  not  intended,  it  may  be  prevented 
by  the  use  of  the  attribute  ' new-layout -ob ject ' . 

The  attribute  'new-layout-object'  may  be  applied  to  logical  components  of  the 
types  NumberedSegment,  Peiragraph,  Number,  FootnoteRef erence,  BodyText, 
BodyRaster  and  BodyGeometric ,  whenever  a  change  in  column  layout  is  required. 

The  attribute  "new  layout  object"  may  specify  the  identifier  of  the  frame  class 
that  represents  the  single,  snaking  or  synchronized  column  area  required.  In  the 
case  of  single  or  synchronised  column  areas,  the  attribute  "new  layout  object" 
may  indicate  the  category  name  corresponding  to  the  frame  class  of  the  single 
column  area  or  of  any  of  the  columns  within  the  synchronised  column  area  that  is 
required. 

When  layout  occurs  in  a  snaking  coliunns  area,  column  breaks  may  be  indicated  by 
using  the  attribute  "new  layout  object".  This  attribute  may  specify  the 
identifier  or  the  category  name  of  the  frame  corresponding  to  the  column  in 
which  the  layout  is  to  continue.     However  only  the  use  of  a  category  name  will 
ensure  that  a  single  column  break  is  always  obtained,  irrespective  of  the  fraune 
class  actually  used. 

When  the  layout  is  to  occur  in  a  synchronized  columns  area,  category  names  are 
used  to  control  the  particular  columns  that  are  to  be  used  to  layout  the  logical 
entities .  Each  colvunn  within  a  synchronized  columns  area  shall  have  a  different 
permitted  category  and  each  basic  logical  entity  to  be  laid  out  in  this 
pcurticular  eurea  shall  have  a  category  name  corresponding  to  a  name  allocated  to 
one  of  the  columns.  The  logical  entities  allocated  to  different  columns  may  be 
aligned  using  the  attribute  "synchronization". 

6.4.1.3.2    Layout  of  footnotes 

The  logical  objects  derived  from  basic  logical  constituent  constraints  that 
represent  the  content  belonging  to  a  footnote  (i.e  FootnoteNumber  and 
FootnoteText)  are  constrained  to  be  laid  out  in  a  footnote  area  which  is 
represented  by  a  FootnoteArea  frame  ( see  6.3.5.9). 

This  constraint  is  specified  by  means  of  category  names.  That  is,  the  logical 
constituents  of  the  types  FootnoteNumber  and  FootnoteText  and  layout 
constituents  of  the  type  FootnoteArea  are  all  required  to  have  the  category  name 
'Footnote' . 

More  than  one  footnote  may  be  placed  in  a  footnote  area  within  a  given  body 
area,  in  this  case  the  content  belonging  to  the  footnotes  are  laid  out 
sequentially  in  the  footnote  area  in  accordance  with  their  reading  order. 

If  the  content  belonging  to  a  footnote  cannftt  all  be  accommodated  in  the 
footnote  area  on  one  page,  then  the  content  may  freely  flow  into  the  footnote 
area,  on  the  next  page.  Alternatively,  it  is  possible  to  specify  that  a  footnote 
is  to  be  laid  out  entirely  within  a  particular  footnote  area.  This  is  achieved 
using  the  attribute  "indivisibility". 
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€.4.1.4    Allocation  of  content  to  header-footer  areas 

A  header  or  footer  area  nay  be  basic  or  composite  (see  6.3.6.1).  In  the  case  of 
a  basic  area,  the  frame  representing  that  area  specifies  the  attribute  "Logical 
source"  which  indicates  the  particuleu:  instance  of  the  constituent  constraint  of 
the  type  CommonContent  that  is  to  be  leiid  out  in  that  area.  The  basic  logical 
constituents  subordinate  to  CommonContent  are  then  laid  out  in  accordance  with 
their  sequential  order. 

In  the  case  of  a  composite  header  or  footer  area  (see  6.3.6.3),  the  area  is 
divided  into  one  or  more  separate  areas,  each  of  which  is  represented  by  a 
lowest  level  frame.  The  content  allocated  to  the  separate  sureas  may  be  derived 
from  one  of  two  sources.  That  is,  the  content  may  be  pre-defined  and  represented 
by  one  or  more  blocks  which  are  directly  associated  with  the  lowest  level  frame. 
Alternatively,  the  lowest  level  frame  may  specify  the  attribute  "logical  source" 
which,  as  above,  indicates  the  particular  logical  object  of  the  type 
CommonContent  that  is  to  be  laid  out  in  that  frame. 


6.4.2    Layout  of  the  document  content 

Various  constraints  may  be  specified  to  control  the  layout  of  the  content  into 
the  body,  header  and  footer  areas.  These  constraints  are  described  below. 

6.4.2.1  Margins 

The  margins  are  the  minimum  distances,  or  offsets,  between  a  part  of  the 
document  content  and  the  edge  of  the  particular  area  in  which  that  content  is 
laid  out.  The  margins  define  the  maximum  extents  of  the  available  area  into 
which  the  content  shall  be  positioned. 

Margins  may  be  specified  for  any  constituent  constraint  representing  a  basic 
logical  object;  different  msurgin  values  may  be  specified  for  different 
constituent  constraints  without  restriction. 

Four  margins  may  be  independently  specified  for  each  constituent  constraint, 
namely: 

**         trailing  edge  margin; 

leading  edge  margin; 

-  right  hand  edge  margin; 

-  left  hand  edge  mzurgin. 

These  margins  are  defined  in  relationship  to  the  layout  path  specified  for  the 
frame  in  which  the  content  is  to  be  laid  out  in  (see  Figure  10). 
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Any  combination  of  the  above  margins  may  be  specified  for  a  particular 
Constituent  constraint.  These  margins  are  specified  by  the  attribute  "offset". 
Any  value  may  be  specified  in  units  of  BMUs.  If  a  particular  margin  is  not 
specified,  then  it  is  assumed  to  be  0  BMUs. 


6.4.2.2  Separation 

Leading  separations  is  the  minimum  distance  between  one  basic  logical  object  and 
the  next  one,  if  any,  when  they  are  laid  out;  trailing  separation  is  the  minimum 
distance  between  one  basic  logical  object  and  the  previous  one,  if  any,  when 
they  are  laid  out.    Both  nay  be  specified  for  basic  logical  components  of  any 
constituent  constraint  types.    These  distances  are  specified  in  BMUs  by  the 
attribute  "separation".    If  no  value  is  specified,  then  the  minimum  distauice  is 
asstuned  to  be  0  BMUs. 

6.4.2.3  Indivisibility 

Indivisibility  provides  the  means  to  specify  whether  or  not  a  logical  object 
derived  from  a  basic  or  composite  logical  constituent  constraint  is  allowed  to 
be  split  over  more  than  one  page  or  over  more  than  one  area  within  a  page.  It 
■ay  be  specified  for  constituent  constraints  of  the  types  Passage, 
NumberedSegment,  Paragraph,  Footnote,  Number,  FootnoteReference  and  BodyText. 
The  attribute  "indivisibility"  is  used  to  specify  this  feature. 


6.4.2.4    Sana  layout  object 

Same  layout  object  provides  the  means  to  specify  that  the  start  of  the  content 
associated  with  a  logical  object  and  the  end  of  the  content  associated  with  the 
previous  logical  object  are  to  be  laid  out  within  a  single  layout  object.  This 
nay  be  specified  for  logical  objects  of  the  types  NumberedSegment,  Paragraph, 
Number,  Footnote,  FootnoteReference,  BodyText,  BodyRaster  and  BodyGeometric . 
The  attribute  "same  layout  object"  is  used  to  specify  this  feature. 
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6.4.2.5  Concatenation 

Concatenation  provides  the  means  to  specify  that  the  content  associated  with  a 
logical  object  derived  from  a  basic  logical  constituent  constraint  and  the 
content  associated  with  the  logical  object  derived  from  previous  basic  logical 
constituent  constraint  are  to  be  regarded  as  an  unbroken  stream  of  content.  This 
nay  be  specified  for  constituent  constraints  of  the  types  BodyText,  Number, 
FootnoteReference,  FootnoteText,  CommonText  and  PageNumber.  The  attribute 
"concatenation"  is  used  to  specify  this  feature. 

6.4.2.6  Block  alignment 

Block  alignment  allows  the  content  associated  with  a  basic  logical  entity  to  be 
specified  as  'left  aligned',   'right  aligned'  or  'centred'  within  the  area  in 
which  that  content  is  laid  out.  Left  aligned  means  that  the  content  is  laid  out 
adjacent  to  the  left  hand  edge  margin.  Right  aligned  means  that  the  content  is 
laid  out  adjacent  to  the  right  hand  edge  margin  and  centred  means  that  the 
content  is  laid  out  midway  between  the  left  and  right  margins. 
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This  feature  may  only  be  specified  using  the  attribute  "block  alignment"  for 
constituent  constraints  of  the  types  Number,  FootnoteRef erence,  FootnoteText, 
PageNumber,  FootnoteNumber ,  BodyText  and  CommonText,  when  they  contain  formatted 
character  content,  BodyRaster,  cuid  BodyGeometric ,  CommonRaster  and 
CommonGeometric . 

6.4.3    Layout  controls  applicable  in  the  absence  of  a  generic  layout  structiire 

In  processsdsle  form  documents  the  generic  layout  structure  is  optional.  If  the 
generic  layout  structure  is  omitted,  then  it  is  the  responsibility  of  the 
receiver  to  define  an  appropriate  layout  structure.  No  limitations  are  placed  on 
the  layout  structure  that  is  used. 

When  a  generic  layout  structure  is  not  specified  within  a  processable  form 
docxment,  then  restrictions  are  placed  on  the  layout  control  functions  described 
in  6.4.1  and  6.4.2  that  may  be  specified  within  the  document.  These  restrictions 
are  indicated  below. 

a)  It  is  not  possible  to  specify  that  certain  logical  parts  of  a 
document  are  to  be  allocated  to  a  given  page'  set  or  that  a  part  of  a 
document  is  to  be  laid  out  starting  in  a  new  page  set,  as  defined  in 
6.4.1.1. 

b)  It  is  possible  to  specify  page  breaks  as  defined  in  6.4.1.2  but  it  is 
only  possible  to  indicate  that  the  layout  shall  begin  on  a  new  page. 
It  is  not  possible  to  specify  a  particular  page  class. 

c)  The  logical  parts  of  the  document  that  are  intended  to  be  laid  out  in 
the  body  area  and  in  the  header/ footer  areas  of  each  page  may  be 
distinguished  from  each  other  by  means  of  application  comments 
specified  for  them  (see  6.6.4).  An  exception  is  that  it  is  not 
possible  to  distinguish  whether  a  particular  portion  of  the  common 
content  is  to  be  placed  in  a  header  or  footer  area  (or  both) . 

d)  It  is  not  possible  to  indicate  the  type  of  layout  area  to  be  used  to 
layout  each  logical  constituent  in  the  body  part  of  a  document.  That 
is,  it  is  not  possible  to  indicate  whether  single  column  or  multiple 
column  areas  are  to  be  used  (see  6.4.1.3.1).  This  shall  be  decided  by 
the  receiver. 

e)  Footnotes  within  the  body  part  of  a  document  may  be  distinguished  by 
use  of  the  attribute  "application  comments".  Footnotes  are  intended 
to  be  read  and  laid  out  separately  from  the  other  logical 
constituents  of  the  body  part  (see  6.4.1.3.2).  However,  it  is  the 
responsibility  of  the  receiver  to  decide  how  footnotes  are  laid  out. 

f)  Margins,  separation,  indivisibility,  same  layout  object, 
concatenation,  and  block  alignment,  as  defined  in  6.4.2  may  all  be 
specified.  Only  one  restriction  applies.  Indivisibility  (see  6.4.2.3) 
may  be  assumed  to  specify  that  a  logical  constituent  constraint  is 
not  to  split  over  more  than  one  page  but  indivisibility  shall  not  be 
specified  for  other  types  of  layout  areas  such  as  single  or  multiple 
column  areas. 
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6.5    Content  layout  and  imaging  characteristics 

A  document  may  contain  character,  raster  graphics  and  geometric  graphics 
content . 

The  content  architectures  that  may  be  specified  using  the  attribute  "content 
architecture  class"  atq  formatted  character,  processable  chairacter,  formatted 
processable  character,  formatted  processable  raster  graphics  aad  formatted 
processable  geometric  graphics.  Any  of  these  may  be  specified  as  the  default  in 
the  document  profile. 


6.5.1    Character  content 


6.5.1.1  Introduction 

This  subclause  defines  the  features  that  are  applicable  to  the  character  content 
contained  in  a  document  and  the  presentation  attributes  and  control  functions 
that  may  be  used  to  specify  these  features.  These  features  may  apply  to  basic 
logical  and  layout  components  unless  otherwise  indicated. 

The  default  values  for  the  following  features  may  be  specified  in  the  dociiment 
profile: 

-  graphic  character  sets; 
graphic  character  subrepertoire ; 

-  code  extension  announcers; 

-  line  spacing; 

-  character  spacing; 
cheuracter  path; 

-  line  progression; 

-  character  orientation; 

graphic  rendition,  including  the  parameters  values: 
default  rendition,  increased  intensity  (bold) ,  italicised, 
underlined,  crossed  out,  primary  font,  1st  alternative  font,  2nd 
alternative  font,  3rd  alternative  font,  4th  alternative  font,  5th 
alternative  font,  6th  alternative  font,  7th  alternative  font,  8th 
alternative  font,  9th  alternative  font,  doubly  underlined,  normal 
intensity,  not  italicised,  not  underlined,  not  crossed  out; 


44 


FOD26  Paz~t  1  -  Document  Application  Profile 


July  1992 


-  line  layout  taJale; 

-  indentation; 

-  alignment; 

-  first  line  offset; 
itemization; 

-  widow  size; 

-  orphan  size; 

-  character  fonts; 

-  kerning  offset; 

-  proportional  line  spacing; 

-  initial  offset. 

The  specification  in  a  document  of  a  non-basic  feature  by  a  presentation 
attribute  or  control  function  t;hall  be  indicated  in  the  document  profile. 

6.5.1.2  Character  content  architecture  class 

Processable  and  formatted  processcQ^le  form  documents  may  contain  processeible, 
formatted  or  formatted  processad^le  character  content.  Formatted  form  documents 
may  contain  formatted  and  fonnatted  processable  character  content. 

When  using  character  content,  any  number  of  content  portions  may  be  associated 
with  a  basic  component. 

The  content  information  in  a  content  portion  may  be  absent.  This  is  to  allow  the 
representation  and  interchange  of  dociiments  in  which  parts  of  the  content  may  be 
supplied,  for  example,  during  subsequent  editing. 

6.5.1.3  Character  repertoires 

The  basic  character  repertoire  supported  by  this  profile  is  composed  of  the  94 
characters  of  ISO-IR6  (the  IRV  of  ISO  646  revised  1991)  plus  the  character 
space. 

Any  other  graphic  character  set  which  is  registered  in  accordance  with  ISO  2375 
may  be  designated  and  invoked  at  any  point  in  the  document  provided  its  use  is 
indicated  in  the  docviment  profile  as  a  non-basic  value  using  the  character 
presentation  feature  "graphic  character  sets".  No  locking  shift  functions  are 
specified  in  this  presentation  feature. 

The  code  extension  techniques  allowed  for  the  designation  and  invocation  of 
character  sets  to  the  left  hand  side  and  right  hand  side  of  the  8-bit  code  table 
(GL  and  GR  respectively)  are  defined  in  6.5.1.4. 
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Using  these  code  extension  techniques,  the  graphic  character  sets  designated 
and/or  invoked  at  the  beginning  of  a  content  portion  containing  character 
content  are  specified  by  the  presentation  attribute  "graphic  character  sets". 
The  graphic  character  sets  may  also  be  changed  at  any  point  within  a  content 
portion. 

The  default  graphic  character  sets  which  apply  to  the  content  portions  within  a 
document  may  be  specified  in  the  document  profile  using  the  presentation 
attribute  "graphic  character  sets". 

If  the  character  set  defined  in  ISO  6937-2  with  or  without  Addendxim  1  is 
designated  and  invoked,  then  the  use  of  any  of  its  subrepertoires  registered 
according  to  ISO  7350  may  be  specified  using  the  presentation  attribute  "graphic 
character  subrepertoire" .  All  sub-repertoires  are  non-basic  and  their  use  shall 
be  indicated  in  the  document  profile.  The  subrepertoire  shall  not  be  changed 
within  a  content  portion. 

NOTES 

1:        The  basic  character  repertoire  supported  by  this  profile  is  not  the 
standard  default  value  specified  in  [ISO  8613-6 |CCITT  Recommendation 
T.416];  hence  it  may  be  necessary  to  specify,  in  the  document  profile 
of  a  particular  document,  that  this  is  the  default  value  being  used 
for  that  document. 

2:        Revised  CCITT  Recommendations  T.50  and  T.51  and  new  CCITT 

Recommendation  T.52  are  under  preparation.  CCITT  Recommendations  T.50 
and  T.51  are  intended  to  be  completely  compatible  with  ISO  646 
revised  1991  (ISO  IR-6)  and  ISO  6937  (under  revision)  respectively. 


6.5.1.4    Code  extension  techniques 

The  code  extension  techniques  specified  in  ISO  2022  may  be  used  subject  to  the 
following  restrictions : 

i)  GO  sets  only  ISO-IR6  (the  IRV  of  ISO  646  revised  1991),  ISO-IR2  (the 
primary  set  of  ISO  6937-2),  or  any  other  version  of  ISO  646  may  be 
designated  for  this  set;  these  graphic  character  sets  may  only  be 
invoked  in  GL. 

ii)  Gl,  G2,  G3  sets:  no  restrictions  sure  placed  on  the  character  sets 
that  may  be  designated  for  these  sets;  these  graphic  character  sets 
may  only  be  invoked  in  GR. 

iii)  The  locking  and  single  shift  functions  allowed  are  as  follows: 

-  LSO  to  invoke  the  GO  set  into  GL; 

-  LSlR  to  invoke  the  Gl  set  into  GR; 

-  LS2R  to  invoke  the  G2  set  into  GR; 

-  LS3R  to  invoke  the  G3  set  into  GR; 

-  SS2  to  invoke  one  character  from  the  G2  set  into  GL; 

-  SS3  to  invoke  one  character  from  the  G3  set  into  GL. 


(Here  GL  and  GR  refer  to  the  left  and  right  hand  parts  respectively 
of  the  8-bit  code  table) 
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When  specifying  the  presentation  attribute  "graphic  character  sets", 
it  is  necesssury  to  invoke  character  sets  for  both  GL  and  GR.  Thus  an 
allowed  character  set  shall  be  designated  into  GO  (see  item  i)  above) 
and  invoked  into  GL.  It  is  also  necessary  to  invoke  a  character  set 
into  GR  which  has  been  designated  into  the  Gl,  G2  or  G3  set. 

V)        The  empty  set  shall  be  designated  into  Gl  and  invoked  into  GR  if  no 
other  specific  chauracter  set  is  invoked  into  GR. 

The  code  extension  techniques  allowed  are  illustrated  in  figures  11  and  12. 

The  announcement  and  encoding  of  these  functions  are  to  be  as  specified  in  ISO 
2022. 

The  code  extension  techniques  that  are  used  or  may  be  used  in  a  basic  component 
shall  be  specified  by  the  presentation  attribute  "code  extension  announcers." 
The  default  code  extension  announcers  used  throughout  a  document  aiay  be 
specified  in  the  document  profile,  using  the  presentation  attribute  "code 
extension  announcers". 

NOTE  -  In  accordance  with  [ISO  8613-6 jcciTT  Recommendation  T.416],  there  is 
no  restriction  concerning  the  number  of  graphic  character  sets  which  may  be 
designated  and/or  invoked  in  the  presentation  attribute  "graphic  character 
sets"  providing  the  restrictions  defined  in  this  subclause  are  applied. 
Hence  designation  to  a  particular  G  set  overrides  a  previous  designation  to 
that  set  and  invocation  to  GL  or  GR  overrides  the  previous  invocation  to 
the  GL  or  GR  respectively.  Thus  the  sequential  order  of  designation  and/or 
invocation  sequences  in  the  attribute  "graphic  cheoracter  sets"  is 
significant. 

Figure  11  -  Code  extension  features  (basic  case) 
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6.5.1.5    Line  spacing 

Any  value  of  line  spacing  may  be  specified.  Values  of  150,  200,  300  and  400  BMUs 
are  basic;  the  use  of  any  other  value  in  a  document  is  non-basic  and  shall  be 
indicated  in  the  document  profile. 

The  line  spacing  nay  be  specified  at  the  beginning  of  the  content  associated 
with  a  basic  component  using  the  presentation  attribute  "line  spacing**.  The 
value  may  be  changed  anywhere  within  the  content  portion  using  the  control 
functions  SVS  and  SLS. 


6.5.1.6    Character  spacing 

Any  value  of  character  spacing  may  be  specified.  Values  greater  than  or  equal  to 
100  are  basic;  the  use  of  any  other  value  in  a  document  is  non-basic  and  shall 
be  indicated  in  the  document  profile. 

The  character  spacing  may  be  specified  at  the  beginning  of  the  content 
associated  with  a  basic  component  using  the  attribute  **character  spacing".  The 
value  may  be  changed  anywhere  within  a  content  portion  using  the  control 
functions  SHS  or  SOS. 
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NOTES 


1: 


A  character  spacing  of  160  BMUs  is  provided  for  use  with  Korean  Ban- 
gui characters. 


2: 


SHS  peurameters  of  0,  1,  2,  3  and  4  are  provided.  The  use  of 
parameters  5  and  6  nay  be  provided  in  a  future  edition  of  this 
standard  for  use  with  Chinese  characters. 


6.5.1.7    Character  path  and  line  progreesion 

Both  horizontal  and  vertical  writing  directions  may  be  used  within  a  document. 
In  the  case  of  horizontal  writing,  the  characters  progress  either  from  left  to 
right  or  from  right  to  left  across  the  page  and  the  line  progression  is  from  the 
top  of  the  page  to  the  bottom.  In  the  case  of  vertical  writing,  the  characters 
progress  from  the  top  of  the  page  to  the  bottom  and  the  line  progression  is  from 
the  right  to  the  left.  The  use  of  these  writing  directions  is  restricted  by  the 
page  layout  type  used. 

^or  page  layout  A,  only  horizontal  writing  may  be  used  in  the  body,  header  and 
footer  areas.  Thus,  in  this  case  the  cheuracter  path  and  line  progression  is 
specified  either  as  0  and  270  degrees  respectively  or  180  and  90  degrees 
respectively. 

For  page  layout  B,  again  only  horizontal  writing  may  be  used  in  the  body,  header 
and  footer  areas.  However,  in  this  case  the  content  in  the  body  area  is 
presented  for  viewing  with  the  page  in  landscape  orientation  and  the  content  in 
the  header  and  footer  areas  is  presented  for  viewing  when  the  page  is  in  the 
portrait  orientation. 

Thus  for  page  layout  B,  in  the  body  area  the  character  path  and  line  progression 
is  specified  either  as  90  and  270  degrees  respectively  or  270  and  90  degrees 
respectively.  In  the  header  and  footer  areas,  the  character  path  and  line 
progression  is  specified  as  in  page  layout  A. 

For  page  layout  C,  only  vertical  writing  nay  be  used  in  the  body  aurea  and  only 
horizontal  writing  may  be  used  in  the  header  and  footer  areas.  Thus  in  the  body 
area  the  character  path  and  line  progression  are  specified  as  270  and  270 
degrees  respectively.  In  the  header  and  footer  areas,  the  character  path  and 
line  progression  is  specified  as  in  page  layout  A. 

For  page  layout  D,  only  vertical  writing  may  be  used  in  the  body,  header  and 
footer  areas.  Thus  in  all  these  areas,  the  character  path  and  line  progression 
are  specified  as  270  and  270  degrees  respectively. 

A  character  path  value  of  0  degrees  and  a  line  progression  value  of  270  degrees 
are  basic  values.  All  other  values  are  non-basic  and  their  use  in  a  document 
shall  be  indicated  in  the  document  profile. 

The  values  of  character  path  and  line  progression  may  be  specified  at  the 
beginning  of  the  content  associated  with  a  basic  component  using  the 
presentation  attributes  "character  path"  and  "line  progression"  respectively. 
These  values  cannot  be  changed  within  a  content  portion. 
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S.S.ioO    Character  orientation 

Tk@  character  orientation  m&y  be  specified  as  0  or  90  degrees  depending  on 
whether  vertical  or  horizontal  writing  is  used  (see  6.5.1.7). 

when  horizontal  writing  is  used,  characters  may  only  be  orientated  at  0  degrees. 
Mhen  vertical  writing  is  used,  characters  ma^  be  orientated  at  90  degrees. 

A  value  o£  0  degrees  is  basic;  a  value  of  90  degrees  is  non-basic  and  its  use  in 
a  document  ehall  be  indicated  in  the  document  profile. 

The  value  of  the  character  orientation  ia  specified  at  the  beginning  of  the 
content  associated  with  a  basic  component  by  the  presentation  attribute 
"character  orientation".  This  value  cannot  be  changed  within  the  content. 

§,5,1,9  Emphasis 

The  following  modes  of  emphasising  graphic  characters  may  be  distinguished: 

-  normal  rendition i 
'  normal  intensity; 

-  increased  intensity  (bold) ; 

-  italicized; 

'     -  not  italicized; 

-  underlined; 

.  .-  doubly  underlined; 

-  not  underlined; 

-  crossed-out; 

.  f  not  crossed-out. 

All  the  above  mentioned  modes  of  emphasis  are  basic.  If  no  default  mode  is 
explicitly  specified  in  the  document  profile,  then  the  default  mode  is  normal 
rendition. 

The  mode  of  emphasis  may  be  specified  at  the  beginning  of  the  content  associated 
with  a  basic  component  using  the  presentation  attribute  "graphic  rendition".  The 

mode  may  be  changed  2mywhere  within  the  content  using  the  control  function  SGR. 
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The  mode  of  emphasis  remains  in  effect  within  the  content  associated  with  a 
basic  component  until  changed  into  a  mutually  exclusive  mode  or  by  the 
specification  of  'normal  rendition'.    Mutually  exclusive  modes  are  normal/ 
increased  intensity,  italicized/not  italicized,  underlined/doubly  underlined/not 
underlined  and  crossed  out/not  crossed>-out.    One  mode  from  each  mutually 
exclusive  set  may  be  in  operation  at  any  point  in  the  document  content. 

Normal  rendition  cancels  the  effect  of  all  modes  of  emphasis  that  are  currently 
in  operation  and  specifies  that  the  text  shall  be  displayed  in  accordance  with 
the  default  rendition  parameters  set  for  the  presentation  device.  Thus,  for 
example,  if  it  is  required  to  ensure  that  the  content  is  not  underlined,  then  it 
is  necessary  to  explicitly  specify  that  underlined  is  not  to  be  used. 

6.5.1.10  Tabulation 

TeUaulation  stop  positions  may  be  specified  at  any  position  along  the  character 
path.  Each  stop  is  specified  by  means  of  the  following: 

a)  The  tabulation  position  relative  to  the  margin  position  in  the 
direction  opposite  to  the  character  path; 

b)  An  optional  alignment  qualifier  that  specifies  the  type  of  alignment 
to  be  used  at  the  designated  tabulation  position.  The  type  may  be 
specified  as  one  of  the  following: 

start  aligned; 

-        end  aligned; 

centred; 

aligned  around. 

These  alignment  qualifiers  are  defined  in  (ISO  8613-6 jcciTT  Recommendation 
T416].  If  the  alignment  qualifier  is  not  explicitly  specified,  then  it  is 
assumed  that  start  aligned  is  to  be  used. 

Only  one  set  of  tabulation  stops  can  be  specified  to  be  applicable  to  the 
content  associated  with  a  basic  component.  No  limit  is  placed  on  the  number  of 
tabulation  stops  that  may  be  specified  within  a  given  set. 

The  set  of  teOsulation  stop  positions  associated  with  the  content  of  a  basic 
component  are  specified  using  the  presentation  attribute  "line  layout  table". 
TsUsulation  stop  positions  are  invoked  within  the  content  using  the  control 
function  STAB. 

The  tabulation  reference  numbers  used  in  the  STAB  controls  and  associated 
presentation  attribute  "line  layout  table"-  shall  be  chosen  so  that,  in  any  given 
line  layout  table  the  reference  numbers  are  unique,  sequential  in  the  direction 
of  the  character  path  and  do  not  include  leading  zeroes. 
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6.5.1.11  Indentation 

Indentation  is  the  distance  between  the  first  character  on  a  line  of  content  and 
the  position  of  the  margin  that  is  in  the  direction  opposite  to  the  direction  of 
the  character  path.  Thus  the  value  of  the  indentation  specified  determines  the 
line  home  position  (as  defined  in  [ISO  8613-6 |CCITT  Recommendation  T.416]). 

Indentation  acts  as  temporary  alteration  in  the  position  of  the  offset  in  the 
direction  opposite  to  the  direction  of  the  cheucacter  path.    When  text  is 
formatted,  it  is  intended  to  be  laid  out  between  the  indentation  position  and 
the  margin  position  in  the  direction  of  the  character  path. 

Any  value  of  indentation  may  be  specified  for  basic  logical  components  using  the 
presentation  attribute  "indentation".  The  indentation  value  shall  not  be  changed 
within  a  content  portion. 

6.5.1.12  Alignment 

This  feature  is  concerned  with  how  the  first  and  last  characters  on  each  line  of 
character  content  are  to  be  laid  out  during  the  formatting  process. 

The  following  values  of  alignment  may  be  specified  as  basic: 

-  start  aligned; 
end  aligned; 

-  centred; 
justified. 

The  semantics  of  these  values  are  as  defined  in  [ISO  8613-6 jcciTT  Recommendation 
T.416] . 

The  presentation  attribute  "alignment"  is  used  to  specify  the  alignment  that  is 
applicable  to  the  content  associated  with  a  basic  component.  The  alignment  value 
cannot  be  changed  within  a  content  portion. 

6.5.1.13  First  line  format 

This  feature  specifies  how  the  first  line  of  the  content  associated  with  a  basic 
component  is  to  be  laid  out  and  provides  for  the  itemisation  of  paragraphs. 

It  allows  the  first  character  in  the  content  to  be  positioned  at  some  point 
along  the  character  path  relative  to  the  indentation  position  (as  specified  in 
6.5.1.11).  This  point  may  be  in  the  direction  of  the  character  path  or  in  the 
direction  opposite  to  the  direction  of  the  character  path  relative  to  the 
indentation  position. 
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In  addition,  this  feature  provides  for  the  specification  of  an  item  identifier 
on  the  first  line.  The  item  identifier  is  a  string  of  characters  that  precedes 
and  is  separated  from  the  remaining  characters  that  form  the  first  line.  The 
control  function  CR  (Carriage  Return)  is  used  as  the  separator. 

The  features  provided  correspond  to  examples  10.1  to  10.5  shown  in  figure  10  of 
[ISO  8613-6 |CCITT  Recommendation  T.416]. 

First  line  format  is  specified  by  the  presentation  attributes  "first  line 
offset"  £md  "itemisation" ,  and  "indentation".    Only  those  values  of  the 
attributes  which  combine  to  form  the  examples  shown  in  figure  10  of 
[ISO  8613-6 |CCITT  Recommendation  T.416]  may  be  used. 

6.5.1.14    Widow  and  orphan  sizes 

The  widow  size  specifies  the  minimum  number  of  lines  of  content  that  shall  be 
allocated  to  a  following  frame  or  page  when  the  content  associated  with  a  basic 
logical  component  is  laid  out  such  that  it  flows  over  two  frames  or  pages.  To 
accommodate  this,  it  may  be  necessary  to  move  a  number  of  lines  of  content  from 
one  frame  or  page  to  the  next  frame  or  page. 

The  orphan  size  specifies  the  minimum  number  of  lines  of  content  that  shall  be 
placed  in  the  current  frame  or  page  when  the  content  associated  with  a  basic 
logical  component  is  split  over  two  frames  or  pages.  If  this  minimum  cannot  be 
accommodated,  then  the  whole  content  shall  be  placed  in  the  next  frame  or  page. 

Any  value  of  widow  or  orphan  size  may  be  specified  using  the  presentation 
attributes  "widow  size"  and  "orphan  size"  respectively. 

Widow  and  orphan  size  may  only  be  specified  for  character  content  placed  in  body 
area  of  pages. 


6.5.1.15  Fonts 

Any  number  of  fonts  may  used  within  a  document.  The  fonts  used  in  a  particular 
document  are  specified  in  the  document  profile  using  the  attribute  "fonts  list". 

Further  information  concerning  the  specification  of  font  references  in  the 
document  profile  is  given  in  Annex  B,2. 

The  fonts  that  may  be  used  within  the  content  associated  with  each  basic 
component  are  specified  by  the  presentation  attribute  "character  fonts".  Up  to 
10  fonts  taken  from  the  list  specified  by  the  attribute  "fonts  list"  may  be 
specified  by  the  attribute  "character  fonts". 

The  font  to  be  used  at  the  stsort  of  the  content  associated  with  a  basic 
component  is  specified  using  the  attribute  "graphic  rendition".  The  fonts  used 
within  the  content  may  be  changed  using  the  control  function  SGR. 

The  docviment  profile  may  specify,  using  the  attribute  "character  fonts",  a 
default  set  of  up  to  10  fonts  that  are  applicable  to  the  whole  document. 
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6.5.1.16  Reverse  character  strings 

Bi-directional  writing  is  supported  by  this  profile  (see  6.5.1.7).    Hence,  a 
string  of  characters  in  a  content  portion  associated  with  a  basic  component  nay 
be  specified  to  be  imaged  in  the  reverse  direction  of  the  immediately  preceding 
character  string,  such  strings  may  be  specified  by  the  control  function  SRS  as 
defined  in  [ISO  8613-6|CCITT  Recommendation  T.416]. 

This  control  function  is  provided  for  cases  in  which  the  text  belqngs  to 
different  languages  and  the  character  content  is  written,  for  example,  from  left 
to  right  or  from  right  to  left  within  the  same  line  of  characters,  dependent 
upon  the  language  and/or  character  set  being  used. 

NOTE  -  The  use  of  this  control  function  cannot  be  indicated  in  the  document 
profile.  Thus  it  is  intended  that  implementations  shall  ignore  this  control 
function  when  reverse  character  string  layout  and  presentation  is  not 
supported . 

6.5.1.17  Kerning  offset 

A  kerning  offset  value  for  the  content  associated  with  a  basic  component  may  be 
specified  using  the  presentation  attribute  "kerning  offset".  It  is  necessary  to 
specify  such  a  value  when  certain  fonts  eure  invoked  to  ensure  that  no  part  of 
character  images  are  positioned  outside  the  boundary  of  the  available  area. 

6.5.1.18  Proportional  line  spacing. 

The  use  of  proportional  line  spacing  nay  be  invoked  for  the  content  associated 
with  a  basic  logical  component  using  the  attribute  "proportional  line  spacing" . 
When  this  invocation  occurs,  the  line  spacing  between  each  pair  of  consecutive 
lines  is  determined  in  an  implementation-defined  way  from  the  attributes 
associated  with  the  fonts  used  within  the  two  lines  and  may  vary  from  one  line 
to  the  next.  This  process  is  application  dependent. 

6.5.1.19  Superscripts  and  subscripts 

Superscripts  and  subscripts  may  be  specified  anywhere  within  the  content 
associated  with  a  basic  component  by  using  the  control  functions  FLU  and  PLD. 
The  use  of  these  control  functions  shall  be  in  accordance  with  [ISO  8613-6 |CCITT 
Recommendation  T.416]. 

6.5.1.20  Line  breaks 

The  control  functions  BPH  and  NBH  may  be  inserted  in  processzQsle  form  character 
content  to  indicate  where  line  breaks  may  occur  or  may  not  occur  respectively, 
when  the  content  is  laid  out. 
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6.5.1.21  Substitution  of  characters 

The  control  function  SUB  is  provided  to  represent  characters  produced  by  a  local 
system  that  cannot  be  represented  by  a  character  within  a  character  set 
supported  by  this  profile. 

6.5.1.22  Initial  point 

The  initial  point  which  is  applicable  to  basic  layout  components  may  be 
specified  by  the  attribute  "initial  offset".  Any  value  may  be  specified. 


6.5.1.23    Use  of  control  functions 

The  following  is  a  list  of  all  the  control  functions  and  parameter  values  (where 
applicable)  that  may  be  specified  in  character  content: 

SHS    -  select  character  spacing 

(allowed  parameter  values:  0,1, 2, 3, 4); 

* 

SCS    -  set  character  spacing 

(allowed  peorameter  values:  any); 

SVS    -  select  line  spacing 

(allowed  parameter  values:  any); 

SLS    -  set  line  spacing 

(allowed  parameter  values:  any); 

SGR    -  set  graphic  rendition 

(allowed  parameter  values:     0,  1,  2,  3,  4,  9-19,  21-24,  29); 

STAB  -  selective  tabulation 

(allowed  pareuneter  values:  any); 

SRS    -  start  reverse  string 

(allowed  parcuneters:  any); 

VPB  -  line  position  backward  (allowed  parameter  values:  any); 

VPR  -  line  position  relative  (allowed  parameter  values:  any); 

PLD  -  partial  line  down; 

PLU  -  partial  line  up; 

BPH  -  break  permitted  here; 

NBH  -  no  break  here; 

JFY  -  no  justify; 
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SUB 

-  substitute  chauracter; 

SP 

-  space; 

CR 

-  carriage  return; 

LF 

-  line  feed; 

SOS 

-  steurt  of  string  ; 

ST 

-  string  terminator 

-  code  extension  control  functions  (see  6.5.1.4). 

The  use  of  all  these  control  functions,  with  the  exception  of  SP,  CR,  LF,  SOS 
and  ST  are  described  in  various  sections  in  6.5.1. 

6.5.1.24    Formatting  the  content 

The  attribute  "formatting  indicator"  shall  not  be  specified  within  documents 
that  are  conformant  with  this  profile. 

6.5.2    Raster  graphics  content 
6.5.2.1  Introduction 

This  subclause  defines  the  features  that  are  applicable  to  the  raster  graphics 
content  contained  in  a  document.  These  features  may  apply  to  basic  logical  and 
layout  components  unless  otherwise  indicated. 

The  default  values  for  the  following  features  may  be  specified  in  the  docvunent 
profile: 

type  of  coding; 

-  compression; . 

-  pel  spacing; 
spacing  ratio; 
clipping; 

-  image  dimensions. 

The  specification  in  a  docxunent  of  a  non-basic  feature  by  a  presentation  or 
coding  attribute  or  control  function  shall  be  indicated  in  the  document  profile. 
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6.5.2.2  Raster  graphics  content  architectures 

Only  the  formatted  processable  raster  graphics  content  aorchitecture  class  may  be 
used  in  documents  that  conform  to  this  document  application  profile.  This  type 
of  content  may  be  used  in  processable,  formatted  and  formatted  processable  form 
doctunents . 

When  using  raster  graphics  content,  only  one  content  portion  may  be  associated 
with  an  object  or  object  class. 

The  content  information  in  a  content  portion  may  be  absent.  This  is  to  allow  the 
representation  and  interchange  of  documents  in  which  parts  of  the  content  may  be 
supplied,  for  example,  during  subsequent  editing. 

Also,  the  scalable  or  fixed  dimension  content  layout  process  may  be  used  when 
laying  out  and  imaging  the  content  depending  upon  the  specification  of  the 
presentation  attributes  "pel  spacing"  and  "imaging  dimensions"  as  described  in 
6.5.2.6  and  6.5.2.8.  Both  forms  of  content  layout  processes  may  be  used  in  a 
single  document. 

6.5.2.3  Raster  graphics  encoding  methods 

The  content  may  be  encoded  in  accordance  with  the  encoding  schemes  defined  in 
CCITT  Recommendations  T.4  and  T.6.  In  the  case  of  T.4,  either  the  one- 
dimensional  or  two  dimensional  encoding  scheme  may  be  used.  Also  the  'bit-map 
encoding'  scheme  defined  in  [ISO  8613-7 |cciTT  Recommendation  T.417]  may  be  used. 
All  these  forms  of  encoding  may  be  used  in  a  single  document  and  all  are  basic. 
'Uncompressed'  mode  of  encoding  may  also  be  used  but  as  a  non-basic  feature. 

When  using  the  T.4  or  T.6  encoding  method,  the  relationship  between  the  order  of 
pels  and  the  order  of  bits  in  the  octets  in  the  coded  data  stream  shall  be  such 
that  the  first  pel  in  the  order  of  bits  is  allocated  to  the  least  significant 
bit  of  an  octet.  In  the  case  of  bit-map  encoding,  the  order  of  encoding  shall  be 
that  the  first  pel  is  allocated  to  the  most  significant  bit  of  an  octet. 

In  a  content  portion,  if  content  information  is  specified  then  it  is  required 
that  the  coding  attribute  "number  of  pels  per  line"  is  specified;  the  coding 
attribute  "number  of  lines"  may  also  be  specified.    No  restriction  is  placed  on 
the  values  that  may  be  specified  for  these  coding  attributes.    Thus  this  profile 
places  no  restriction  of  the  size  of  the  pel  arrays  that  may  be  used. 

The  type  of  encoding  method  used  is  specified  by  the  attribute  "type  of  coding" . 
The  use  of  this  attribute  is  non-mandatory.  Thus,  if  this  attribute  is  not 
specified  for  a  particular:  content  portion  and  if  the  content  architecture  class 
specified  corresponds  to  the  formatted  processible  raster  graphics  content 
architecture  class,  then  the  default  encoding  method  is  assumed  to  be  T.6. 

6.5.2.4  Pel  path  and  line  progression 

The  pel  path  and  line  progression  supported  by  this  profile  are  0  degrees  and 
270  degrees  respectively.  This  profile  does  not  allow  the  specification  of  other 
values. 


^7 


FOD26  Part  1  -  Document  Application  Profile 


July  1992 


€.5.2.5  Clipping 

A  8Ub-region  within  a  pel  array  represented  by  a  content  portion  associated  with 
a  basic  component  nay  be  defined  using  the  presentation  attribute  "clipping".  No 
restriction  is  placed  on  the  use  of  this  attribute. 


6.5.2.6  Pel  spacing 

The  pel  spacing  is  the  distance  in  BMUs  between  any  two  pels  on  a  line  when  a 
pel  array  is  imaged.  Any  value  may  be  explicitly  specified  provided  that  the 
spacing  between  pels  is  not  less  than  1  BMU.  The  pel  spacing  need  not  be  an 
integer  value.  Also,  the  value  'null'  may  be  specified,  indicating  that  the 
scalable  layout  process  is  to  be  used. 

The  specification  of  the  value  'null'  or  spacings  of  16,  12,  8,  6,  5,  4,  3,  2, 
and  1  BMU  between  adjacent  pels  are  basic.  The  specification  of  any  other 
spacing  is  non-basic  and  shall  be  indicated  in  the  docvunent  profile. 

The  pel  spacing  applicsdale  to  content  associated  with  basic  logical  components 
is  specified  by  the  presentation  attribute  "pel  spacing" . 

NOTES 

1.  The  basic  pel  spacing  values  listed  above  are  equivalent  to 
resolutions  of  75,  100,  150,  200,  240,  300,  400,  600  and  1200  pels 
per  25.4iiQn  respectively  when  the  document  is  imaged  in  its  specified 
size. 

2.  The  attribute  "pel  spacing"  specifies  two  integers,  the  ratio  of 
which  determines  the  pels  spacing.  No  restriction  is  placed  on  the 
values  of  these  integers. 

6.5.2.7  Spacing  ratio 

The  spacing  ratio  is  the  ratio  between  the  pel  spacing  and  the  line  spacing  when 
a  pel  etrray  is  imaged.  This  ratio  is  used  to  determine  the  line  spacing  from  the 
pel  spacing  specified. 

No  restrictions  are  placed  on  the  value  of  this  ratio  providing  that  the 
resultant  line  spacing  is  not  less  than  1  BMU.    Also,  the  line  spacing  need  not 
be  an  integral  number  of  BMUs.  All  values  eure  basic. 

The  default  value  may  be  specified  in  the  document  profile.  If  no  default  value 
is  explicitly  specified  then  the  default  value  is  the  ratio  1:1,  that  is,  the 
line  spacing  is  equal  to  the  pel  spacing. 

The  spacing  ratio  applicedsle  to  the  content  associated  with  a  basic  logical 
component  is  specified  by  the  presentation  attribute  "spacing  ratio". 
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6.5.2.8    Image  dimensions 

The  image  dimensions  are  the  constraints  to  be  applied  to  the  size  of  the  image 
produced  when  laying  out  a  pel  array  represented  by  a  content  portion  associated 
with  a  basic  logical  component. 

These  constraints  are  specified  for  basic  logical  components  by  the  presentation 
attribute  "image  dimensions".  The  value  of  this  attribute  is  only  taken  into 
account  if  the  value  of  the  attribute  "pel  spacing"  is  'null'. 

6.5.3    Geometric  graphics  content 

A  document  may  contain  graphic  images  composed  of  geometric  graphic  content 
encoded  as  C6M  metafiles  in  accordance  with  ISO  8632.  Each  CGM  figure  shall 
consist  of  a  single  picture  only.  Each  GCM  figure  may  specify  its  minimum 
dimensions . 

Further  information  concerning  the  specification  of  geqmetric  graphics  content 
Information  is  given  in  Annex  B. 

6.6    Miscellaneous  features 

6.6.1  Resource  documents 

Object  classes  of  the  types  BodyText,  BodyRaster  and  BodyGeometric ,  CommonText, 
CommonRaster,  CommonGeometric  and  GenericBlock  may  refer  to  corresponding 
constituents  in  a  resource  document. 

The  constituents  in  the  resource  document  may  refer  to  content  portions  and  to 
layout  and  presentation  styles  that  are  contained  within  the  resource  docximent. 
The  constituents  listed  above  are  the  only  ones  that  are  allowed  to  be 
referenced  from  another  document  via  the  resource  attribute;  however  documents 
used  as  a  resource  document  may  contain  any  combination  of  generic  constituents 
which  is  conformant  to  this  document  application  profile. 

6.6.2  External  documents 

In  the  case  of  processable  and  formatted  processable,  the  generic  logical 
structure,  and  the  generic  layout  structure  if  present,  may  be  contained  in  an. 
external  document.    Note  that  it  is  not  permitted  to  exchange  one  generic 
structure  in  the  interchanged  docximent  whilst  referencing  the  other  through  the 
external  document. 

6.6.3  Border 

Border  may  be  specified  for  all  the  frame  types  defined  in  6.3.5  and  6.3.6  using 
the  attribute  "border" .  Borders  may  also  be  specified  in  presentation  styles . 
All  the  features  of  border  specified  in  [ISO  8613-2 |cciTT  Recommendation  T.412], 
may  be  specified.  The  use  of  border  is  a  non-basic  feature  and  shall  be 
indicated  in  the  document  profile.  Border  shall  not  be  specified  for  the 
constituents  GenericBlock  and  Specif icBlock. 
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6.6.4  Application  coamenta 

Specification  of  the  attribute  "application  comments'*  is  mandatory  for  all 
object  classes  contained  in  a  dociu&ent  that  conforms  to  this  profile. 
Specification  of  this  attribute  is  mandatory  for  all  objects  that  do  not  refer 
to  an  object  class,    specification  of  this  attribute  is  optional  for  all  objects 
that  refer  to  object  classes. 

This  attribute  is  structured  so  that  it  contains  two  fields.  The  first  field  is 
mandatory  when  the  attribute  is  specified  and  contains  a  numeric  string  which 
uniquely  identifies  the  constituent  constraint  applicable  to  the  constituent  for 
which  the  attribute  is  specified.  This  facilitates  the  processing  of  documents. 
A  list  of  these  identifiers  is  given  in  table  2. 

NOTES: 

1:    The  values  of  the  constituent  constraint  numeric  identifiers  are  not 
unique  between  the  logical  and  layout  structures  and  therefore  in  order  to 
identify  the  constituent  constraint  applicable  to  a  constituent  it  is 
necessary  to  know  the  structure  of  which  the  constituent  is  a  p£u:t. 

2:    For  constituent  constraints  that  correspond  to  each  other  between  the 
hierarchically  related  profiles  to  which  this  profile  belongs,  the  same 
constituent  constraint  numeric  identifier  is  specified. 

The  second  field  is  optional  and  may  contain  any  information  that  is  relevant  to 
the  application  or  user.  The  format  of  the  second  field  is  not  defined  in  this 
profile  and  the  interpretation  of  this  field  depends  upon  a  private  agreement 
between  the  originator  and  recipient  of  the  document. 

The  encoding  of  the  attribute  "application  coisnents"  is  defined  in  8.1.3.  and 
8.2.3. 

6.6.5  Alternative  representation 

The  content  information  in  a  content  portion  nay  be  replaced  by  a  string  of 
characters  specified  in  the  attribute  "alternative  representation" .  This 
attribute  may  ba  specified  in  content  portions  that  contain  character,  raster 
graphics  or  geometric  graphics  content. 

The  specification  and  use  of  this  attribute  is  optional.  The  string  of 
characters  specified  shall  belong  to  the  cheuracter  repertoires  indicated  in  the 
document  profile  attribute  "alternative  representation  character  sets"  (see 
6.7.4.3).  If  the  latter  attribute  is  not  explicitly  specified  in  the  document 
profile,  then  the  default  defined  in  ISO  8613  is  assmned.    The  control  functions 
CR,  LF  and  SP  may  also  be  used  within  the  character  string  but  no  other  control 
function  is  allowed;  hence  graphic  character  sets  cannot  be  changed  within  the 
alternative  representation. 

6.6.6  Pag©  MOTberiag 

As  described  in  6.2.4.3,  the  constituent  constraint  PageNumber  contains  a 
content  generator  which  may  refer  to  a  page  number.  This  content  generator  is 
evaluated  when  the  document  is  laid  out  and  this  mechanism  provides  a  means  of 
reproducing  the  appropriate  number  of  each  page  of  a  document. 
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Logical  constituent 

Constituent  constraint 
numeric  identifier 

DocumentLogic  alRoot 

0 

Passage 

1 

Numberedsegment 

2 

Number 

3 

Paragraph 

6 

Footnote 

8 

FootnoteNumber 

9 

FootnoteRe  f erence 

10 

FootnoteBody 

11 

FootnoteText 

12 

BodyText 

14 

BodyRaster 

17 

BodyGeometric 

18 

CommonConte  nt 

19 

CommonText 

20 

CommonRaster 

21 

CommonGeometric 

22 

PageNumber 

40 

Layout  constituent 

Constituent  constraint 
numeric  identifier 

DocumentLayoutRoot 

0 

Pageset 

1 

Page 

2 

RectoPage 

3 

VersoPage 

4 

Compos iteHeader 

5 

VariableCompositeBody 

7 

ColumnFixed 

8 

ColumnVariable 

9 

Snakingcolumns 

10 

SynchronizedColumns 

11 

BasicFloat 

12 

FootnoteArea 

15 

ArrangedContentFixed 

16 

ArrangedContentVeuriedsle 

17 

SourcedContentFixed 

18 

SourcedContentVariedDle 

19 

BasicHeader 

27 

BasicBody 

28 

GenericBlock 

29 

Specif icBlock 

30 

Compos iteFooter 

32 

BasicFooter 

33 
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The  content  generator  has  th©  £©ll©^iHg  foraats 

<string-lit©ralxiii!2a-©5jprxstring~lit©ral> 

The  fomat  of  this  content  generator  ie  defined  in  the  macro  PGMUMBER  (see 
note) . 

The  <8tring-literal>  fields  are  optional  and  are  pre-defined  cheuracter  strings. 
The  basic  character  repertoire  used  to  specify  these  strings  is  the  prineury 
character  repertoire  of  ISO  8859-1.  Any  other  character  repertoire,  and 
subrepertoire  if  appropriate,  nay  be  used  provided  that  it  is  designated  and 
invoked  by  the  appropriate  code  designation  and  innovation  sequences,  and 
indicated  in  the  document  profile  as  a  non-basic  value.  SP  and  no  other  control 
functions  nay  be  used  in  these  strings. 

The  field  <nuai-@Kpr>  is  a  reference  to  a  blBding  PGnum  which  specifies  the 
number  of  the  page  concerned.  This  binding  is  initialised  at  the  document  layout 
root  or  page  set  level  (see  the  macro  INITZALISEPGNUM  in  7.4.1)  and 
automatically  incremented  on  each  successive  page  (see  macro  PAGENUMBER  in 
7.4.1).    By  placing  initialisation  on  the  layout  root,  rather  than  on  the 
pageset  class (es),  the  pagenumbering  nay  be  defined  to  be  continued  from  one 
pageset  to  the  next. 

The  content  associated  with  logical  object  classes  of  the  type  PageNumber  is 
laid  out  in  a  frame  of  one  of  the  following  types:  BasicHeader,  BasicFooter, 
SourcedContentVariable ,  SourcedContentFixed  (see  6.3.6)  using  the  logical  source 
mechanism.  Thus  when  the  appropriate  frame  is  being  laid  out,  the  field  <num- 
expr>  in  the  content  generator  contained  in  a  logical  object  class  of  the  type 
PageNumber  is  evaluated  and  this  determines  the  value  of  the  binding  PGnum  that 
is  associated  with  the  current  page  being  laid  out. 

The  number  associated  with  the  binding  PGnum  is  applied  to  a  string  function 
during  its  evaluation  in  order  to  convert  the  number  into  a  character  string. 
This  enables  the  number  to  be  represented  in  the  form  of  an  Arabic  nxuneric 
string,  an  upper  or  lower  case  Roman  numeric  string  or  an  upper  or  lower  case 
alphabetic  string. 

Each  page  class  nay  refer  to  a  different  instance  of  logical  object  classes  of 
the  type  PageNumber  and  this  allows  different  page  numbering  formats  to  be  used 
for  different  parts  of  the  document. 

An  example  of  page  numbering  is  "Page  X"  which  consists  of  two  concatenated 
character  strings.    The  first  is  the  literal  character  string  'Page'  and  this  is 
concatenated  to  a  string  function  denoted  by  'X'.    When  'K'  is  evaluated  in  a 
particulcu:  instance  it  may,  for  example,  return  the  character  string  'iv,  the 
Roman  numeral  (lower  case)  for  the  number  '4', 

NOTE  -  Unless  otherwise  stated,  the  macros  referred  to  in  this  clause  aire 
defined  in  7.3.1. 


6.6.7    Segment  nmnberirag 

As  described  in  section  6.2.3.4,  the  constituent  Nuster  contains  a  content 
generator  which  when  evaluated  during  the  layout  process  produces  an  identifier 
which  serves  to  identify  the  Numbered  Segment  to  which  the  constituent  Number 
belongs . 
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The  f oxmat  o£  this  identifier  is  as  follows : 

<pre-strxnum-strxsuf-str> 

This  format  is  defined  in  the  macro  SEGMENTNUMBER  (see  note). 

The  fields  <pre-str>  and  <suf-str>  are  optional  prefix  and  suffix  chairacter 
strings  respectively  which  may  be  of  emy  length.  The  basic  character  repertoire 
used  to  specify  these  strings  is  the  primary  character  repertoire  of  ISO  8859-1. 
Any  other  character  repertoire,  and  subrepertoire  if  appropriate,  may  be  used 
provided  that  it  is  designated  and  invoked  by  the  appropriate  designation  and 
innovation  sequences  and  indicated  in  the  document  profile  as  a  non-basic  value. 
No  other  control  functions  may  be  used  in  these  strings. 

The  field  <num-str>  is  the  segment  identifier  which  consists  of  a  single  number 
or  a  sequence  of  two  or  more  numbers,  each  of  which  is  separated  by  a 
'separator'.  The  separator  is  a  character  string  and  may,  for  example,  consist 
of  a  full  stop  or  space.  An  example  of  a  segment  identifier  is  '6.3.4.2.1'.  Thus 
segment  identifiers  have  the  general  form: 

<n\imber>[<separatorxnumber>] . . . 

where  [..]...  indicates  optional  repetition. 

In  a  document,  the  prefix  and  suffix  character  strings  are  string  literals  or 
carried  by  the  bindings  'prefix  -<n>'  and  'suffix  -<n>  respectively.  The 
separator  character  strings  are  carried  by  bindings  of  the  form  <separator~<n>' 
and  the  segment  identifier  <num-str>  is  carried  by  the  binding  'number string- 
<n>' . 

In  all  these  bindings  '<n>'  is  a  sequence  of  one  or  more  digits  which  indicate 
the  depth  of  numbering,  such  that  n=l  indicates  the  number  (prefix,  suffix, 
numberstring  etc)  for  the  nvimbered  segments  immediately  subordinate  to  a 
Passage,  n=2  indicates  the  number  (prefix,  suffix,  separator  etc)  for  the 
numbered  segments  immediately  subordinate  to  the  first  level  of  numbered 
segments,  and  so  on.    The  level  number  shall  be  indicated  using  the  smallest 
possible  number  of  characters,  that  is,  there  shall  be  no  leading  zeroes. 

These  bindings  may  be  initialised  at  the  document  logical  root,  passage  or  at 
any  numbered  segment  level  to  start  the  numbering  scheme  sequence  at  a 
subordinate  level  of  numbered  segment.  They  may  also  be  re-specified  at  any 
level  within  the  numbering  scheme.  The  initialisation  of  bindings  is  specified 
by  the  macro  INITIALISEANY. 

The  placement  of  bindings  initialisations  for  nvunbering  schemes  is  significant. 
Initial  values  for  numbers-n  bindings  shall  be  placed  either  at  the  Passage 
level,  or  on  the  Numberedsegment  class  which  is  superior  to  that  in  which  the 
binding  will  be  referenced.     Similarly,  prefix  and  suffixes  and  separators  shall 
be  initialised  either  at  the  Passage  or  at,  the  immediately  superior 
Numberedsegment  level  to  their  use.     In  particular  note  the  "prefix"  and 
"suffix"  eire  not  inherited  by  lower  levels  in  hierachy  (since  they  belong  to  the 
content  generator  SEGMENTNUMBERS  rather  than  the  binding  Nmnberstrings-n) .  Thus 
to  have  concatenation  to  say  "(l).a",  lower  level  shall  have  a  prefix  of  "("  and 
separator  of " ) . 
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In  order  to  evaluate  the  value  of  ' number string-<n>'  for  each  numbered  segment, 
a  number  is  assigned  to  each  numbered  segment  at  a  given  level.  If  the  nvunbered 
segments  are  all  of  the  same  class  then  this  number  nay  be  determined  by  the 
ORDINAL  niameric  function.  If  they  are  of  different  classes,  then  the  number  is 
carried  by  a  binding  of  the  form  'number-<n>' . 

A  different  binding  of  the  type  'number-<n>'  is  used  for  each  numbered  segment 
level  and  is  initialised  at  a  higher  level  constituent  than  the  one  in  which  it 
is  used.  The  number  associated  with  each  numbered  segment  level  is  automatically 
incremented  for  each  successive  numbered  segment  (see  the  macro  USENUMBERS). 

The  binding  'ntunberstring-<n>'  that  is  applicable  to  a  given  level  of  numbered 
segment  is  now  constructed  as  follows: 

<numberstring-xxseparator-yxnumber-z> 

Hence,  the  segment  identifier  consists  of  a  concatenation  of  up  to  three  fields. 
The  field  <niunberstring-x>  is  a  reference  to  the  segment  identifier  applicable 
to  the  immediately  superior  level  of  numbered  segment  (if  any).  This  identifier 
is  in  the  form  of  a  character  string.  The  field  <8epar£^tor-y>  is  a  reference  to 
a  separator  defined  at  some  higher  level  in  the  document  structure. 

The  field  <number-z>  is  the  number  applicable  to  the  given  numbered  segment 
whose  identifier  is  being  constructed.  As  indicated  above,  this  nvunber  may  be 
determined  from  an  ORDINAL  expression  or  by  reference  to  a  binding  of  the  form 
'number-<n>'  which  is  specified  for  the  same  numbered  segment  whose  identifier 
is  being  constructed.  In  either  case,  a  string  function  is  applied  to  the  number 
to  convert  it  into  a  character  string.  This  string  function  allows  the  number  to 
be  represented  in  one  of  the  following  forms:  Arabic  number  string,  upper  or 
lower  case  Roman  numeral  string,  or  upper  or  lower  case  alphabetic  characters. 
This  construction  is  defined  in  the  macro  USENUMBERSTRINGS . 

The  constructed  binding  of  the  form  '  number string-<n>'  is  then  available  for 
constructing  the  identifiers  at  lower  levels  of  numbered  segments.  This  binding 
is  also  referred  to  in  a  content  generator  carried  by  the  constituent  Ntimber, 
which  causes  the  identifier  (with  optional  prefix  and  suffix  strings)  to  be 
generated  and  reproduced  when  the  document  is  laid  out. 

NOTE  -  The  macros  referred  to  in  this  clause  are  defined  in  7.3.1. 

6.6.8    Footnote  numbering 

A  footnote  niimber  is  a  character  string  that  identifies  a  given  footnote.  The 
format  of  this  string  is  as  follows: 

<string-literalxnum-strxstring-literal> 

This  format  is  defined  in  the  macro  FNOTENUMBER. 

The  <string-literal>  fields  are  optional' and  are  pre-defined  prefix  or  suffix 
character  strings.  The  basic  character  repertoire  used  to  specify  these  strings 
is  the  primary  character  repertoire  of  ISO  8859-1.  Any  other  chauracter 
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repertoire,  and  subrepertoire  if  appropriate,  may  be  used  provided  that  it  is 
designated  and  invoked  by  the  appropriate  designation  and  innovation  sequences, 
and  indicated  in  the  document  profile  as  a  non-basic  value.  No  other  control 
functions  nay  be  used  in  these  strings. 

The  field  <num-str>  is  an  automatically  generated  numeral  or  a  user  supplied 
character  string  that  generally  serves  to  identify  a  particular  footnote. 
Numerals  nay  be  represented  in  the  form  of  Arabic  numerals,  upper  or  lower  case 
Roman  numerals  or  upper  or  lower  case  Alphabetic  characters.  Automatically 
generated  footnote  numbers  are  incremented  sequentially  from  an  initial  value 
which  nay  be  set  to  any  positive  value  at  the  beginning  of  the  document  and 
reset  at  any  passage. 

A  single  binding  ' f noteniimber '  is  provide  to  represent  footnote  numbers.  This 
nay  be  initialised  to  any  non-negative  niunber  at  the  logical  root  or  on  any 
Passage  (see  specification  of  the  macro  INITIALISEFNOTE ) . 

The  footnote  number  is  incremented  using  a  binding  expression  at  each  footnote 
object  (see  the  macro  INCFNOTENUMBER) .  This  is  then  made  into  a  character  string 
using  a  string  function.  This  value  is  assigned  to  the  'binding  'fnotestring' 
(see  the  macro  FNOTENUMBERSTRING) . 

Alternatively,  a  character  string  literal  may  be  assigned  to  the  binding 
'fnotestring' ;  this  provides  the  user  with  the  ability  to  supply  particular 
footnote  labels  for  individual  footnotes  (see  the  macro  FNOTESTRIN6LITERAL ) . 

The  constituents  FootnoteReference  and  FootnoteNumber  contain  content  generators 
whose  format  is  defined  by  the  macro  FNOTENUMBER.  As  indicated  above,  this 
format  consists  of  a  field  represented  by  <num-str>  which  has  optional  prefix 
and  suffix  string  literals.  The  field  <num-str>  consists  of  a  reference  to  a 
binding  ' f notestring '  which  specifies  the  number  of  the  footnote  in  the  form  of 
a  character  string. 

6.6.9  User  readable  commenta 

Information  which  is  to  be  interpreted  as  comments  relevant  to  constituents  and 
associated  content  portions  may  be  specified  using  the  attribute  "user  readedsle 
comments".  This  information  is  intended  for  presentation  to  humans. 

The  information  consists  of  a  string  of  characters  which  shall  belong  to  one  of 
the  character  repertoires  indicated  in  the  document  profile  attribute  "comments 
character  sets"  (see  6.7.4.2).  If  the  latter  attribute  is  not  explicitly 
specified,  then  the  default  defined  in  ISO  8613  is  assumed.    The  control 
functions  CR,  LF,  SP  and  code  extension  control  functions  may  also  be  used 
within  the  character  string  but  no  other  control  functions  are  allowed. 

6.6.10  User  visible  name 

Information  which  may  be  used  to  identify  constituents  within  a  docximent  may  be 
specified  using  the  attribute  "user  visible  name" .  This  information  is  intended 
for  presentation  to  humans,  for  example,  to  assist  in  the  editing  of  documents. 
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The  information  consists  of  a  string  of  characters  which  shall  belong  to  one  of 
the  character  repertoires  indicated  in  the  document  profile  attribute  "comments 
character  sets"  (see  6.7.4.2).  If  the  latter  attribute  is  not  explicitly 
specified,  then  the  default  defined  in  ISO  8613  is  assumed.    The  control 
functions  CR,  L7,  SP  and  code  extension  control  functions  nay  also  be  used 
within  the  character  string  but  no  other  control  functions  are  allowed. 


6.7    Docnaaent  management  features 

Information  relating  to  the  doctiment  as  a  whole  is  specified  in  the  doc\iment 
profile  which  is  represented  by  the  constituent  DocumentProf ile .  This 
constituent  shall  be  specified  in  every  document. 

The  information  in  the  document  profile  is  classified  into  the  following 


categories 

• 
• 

iy 

dociiment  constituent  information; 

ii) 

document  identification  information; 

iii) 

document  default  information; 

iv) 

non-basic  characteristics  information; 

V) 

document  management  information. 

The  information  in  the  document  profile  may  be  of  interest  to  the  user  or  may  be 
used  for  machine  processing  of  the  document. 

6.7.1    Document  constituent  information 

This  information  specifies  which  constituents  are  used  to  represent  the 
document,  including  constituents  that  are  external  to  the  interchanged  document. 
This  information  is  divided  into  three  categories. 

6.7.1.1    Presence  of  document  constituents 

This  information  indicates  which  constituents  are  included  in  the  document.  That 
is,  this  information  indicates  whether  or  not  the  document  contains  a  generic 
logical  structure,  a  specific  logical  structure,  a  generic  layout  structure,  a 
specific  layout  structure,  layout  styles  and  presentation  styles  (see  note).  It 
is  mandatory  to  specify  this  information  in  the  document  profile. 

NOTE  -  If  the  generic  logical  or  layout  structure  is  external  to  the 
document  (see  6.7.1.3),  then  it  is  still  necessary  to  indicate  that  these 
structures  are  present  and  form  part  of  the  document. 
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6.7.1.2    Resource  document  information 

This  information  consists  of  a  reference  to  a  resource  document  ( see  6.6.1). 
This  is  specified  by  the  attribute  "resource  document" .  If  constituents  in  the 
document  contain  references  to  object  classes  in  a  resource  docximent,  then  it  is 
mandatory  to  specify  this  information  in  the  document  profile . 

£.7.1.3    External  document  information 

This  information  consists  of  a  reference  to  an  external  document  which  may 
consist  of  a  generic  logical  structure,  or  both  generic  layout  and  generic 
logical  structures  (see  6.6.2).  If  such  a  reference  is  required,  then  it  is 
specified  by  the  attribute  "external  document  class"  in  the  document  profile. 

6.7.2    Document  identification  information 

This  information  relates  to  the  identification  of  the  document.  This  information 
is  divided  into  six  categories. 

6.7.2.1  Document  application  profile  information 

This  information  indicates  the  document  application  profile  to  which  the 
docxunent  belongs.  It  is  mandatory  to  specify  this  information  using  the 
attribute  "document  application  profile". 

6.7.2.2  Document  architecture  class  information 

This  information  indicates  the  document  £u:chitecture  class  to  which  the  document 
belongs  (see  6.1).  It  is  mandatory  to  specify  this  information  using  the 
attribute  "document  architecture  class". 


6.7.2.3  Content  architecture  classes  information 

This  information  indicates  the  content  architecture  classes  used  in  the  document 
(see  6.5.1.2,  6.5.2.2  and  6.5.3).  It  is  mandatory  to  specify  this  information 
using  the  attribute  "content  architecture  classes". 

6.7.2.4  Interchange  format  class  information 

This  information  indicates  the  interchange  format  class  used  to  represent  the 
document  (see  clause  8).  It  is  mandatory  to  specify  this  information  using  the 
attribute  "interchange  format  class". 
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6.7.2.5    ODh.  version  information 

This  information  indicates  the  ISO  standard  or  CCITT  Recommendation  to  which  the 
document  conforms.  It  also  specifies  a  calendar  date,  which  indicates  that  the 
document  conforms  to  the  version  of  the  ISO  standard  or  CCITT  Recosmendation  and 
any  addenda  that  are  current  on  that  date.  It  is  mandatory  to  specify  this 
information  using  the  attribute  "ODA  version". 


6.7.2.6    Document  reference 

This  information  serves  to  identify  the  document.  Typically  this  information  is 
allocated  to  the  dociunent  by  the  creator  of  the  document.  The  identifier  may 
consist  of  an  ASN.l  object  identifier  or  a  string  of  characters.  It  is  mandatory 
to  specify  this  information  using  the  attribute  "document  reference". 


6.7.3    Document  default  information 

I 

This  information  specifies  various  default  values  for  attributes  used  in  the 
document.  The  default  values  that  are  allowed  are  specified  in  clause  6.  The 
specification  of  this  information  is  only  required  when  it  is  required  to 
specify  a  default  value  which  is  other  than  the  standard  default  value  specified 
in  [ISO  8613|t.410  series  of  CCITT  Recommendations]. 

Default  values  for  the  following  groups  of  attributes  may  be  specified: 

-  document  architecture  attributes; 
character  content  attributes; 

-  raster  graphics  attributes; 

-  geometric  graphics  attributes. 


6.7.4    Non-basic  characteristics  information 

This  information  specifies  the  non-basic  attribute  values  specified  in  the 
document.  It  is  mandatory  to  specify  a  non-basic  attribute  value  in  the  docvtment 
profile  when  such  a  value  is  used  in  the  document. 

The  following  types  of  non-basic  attribute  values  may  be  specified: 

-  profile  character  sets; 

-  comments  character  sets; 

-  alternative  representation  character  sets; 

-  page  dimensions; 
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medium- type 8 ; 

-  layout  paths; 

-  borders; 

character  presentation  features; 

raster  graphics  presentation  features; 

raster  graphics  coding  attributes. 

Fiirther  information  concerning  document  profile,  comments  and  alternative 
representation  cheuracter  sets  is  given  below. 

6.7.4.1    Profile  character  sets 

Some  document  profile  attributes  have  values  consisting  of  character  strings, 
for  example,  the  document  management  attributes.  The  chsiracter  sets  used  in 
^hese  character  strings  axe  specified  by  the  document  profile  attribute  "profile 
character  sets". 

This  attribute  "profile  chairacter  sets"  specifies  a  code  extension  announcer  and 
designations  of  character  sets,  which  are  subject  to  the  following  restrictions: 

i)  The  code  extension  announcer  shall  be  04/03  when  specified.  This 
code  extension  announcer  specifies  the  use  of  GO  and  Gl  sets  in  an  8- 
bit  environment  and  also  the  invocation  of  GO  and  Gl  sets  into  GL  and 
GR  respectively.    Thus,  in  each  attribute  to  which  this  attribute 
applies,  invocation  shift  functions  are  not  necessary,  because  GO  and 
Gl  sets  are  implicitly  invoked  by  this  code  extension  announcer. 

ii)  GO  set:  only  ISO-IR6  (the  IRV  of  ISO  646  revised  1991),  ISO-IR2  (the 
primary  set  of  ISO  6937-2),  or  any  other  version  of  ISO  646  may  be 
designated  for  this  set;  these  graphic  character  sets  eore  implicitly 
invoked  in  GL. 

iii)  Gl:  no  restrictions  are  placed  on  the  graphic  character  sets  that  may 
be  designated  for  this  set;  these  graphic  character  sets  are 
implicitly  invoked  in  GR. 

iv)  The  empty  set  ahall  be  designated  into  Gl  and  invoked  into  GR  if  no 
other  specific  set  is  invoked  in  GR. 

If  the  attribute  "profile  character  sets"  is  not  specified,  then  the  default 
defined  in  ISO  8613  is  assumed. 


€.7.4.2    Comments  character  sets 

The  character  sets  asstimed  to  have  been  designated  and  optionally  invoked  at  the 
beginning  of  the  chuacter  strings  specified  by  the  attributes  "user  readeJale 
comments"  (see  6.6.9)  and  "user  visible  name"  (see  6.6.10)  are  specified  using 
the  document  profile  attribute  "comments  character  sets". 
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It  also  specifies  the  code  extension  techniques  and  the  graphic  character  sets 
which  nay  be  used  in  the  attributes  "user  readable  comments"  and  "user  visible 
name" . 

If  this  attribute  is  specified,  the  code  extension  techniques  which  nay  be  used 
in  the  attributes  "user  readable  comments"  and  "user  visible  name"  ahall  be 
announced  by  appropriate  code  extension  announcers.    The  use  of  GO  set  and  GL 
ehall  always  be  announced.  Other  code  extension  announcers  are  to  be  specified 
according  to  the  requirements  of  a  particular  docximent. 

Two  kinds  of  code  extension  techniques  are  permitted  for  this  attribute.    One  is 
to  use  GL  and  GR  without  shift  functions,  and  the  other  is  to  use  various 
character  sets  by  shift  functions.    The  former  is  rather  restricted  but  no  shift 
functions  are  necessary  in  the  "user  readable  comments"  and  "user  visible  name". 

The  same  restriction  as  in  6.7.4.1  is  applied  in  this  case.    The  latter  permits 
various  usages  of  character  sets  but  invokations  shall  be  specified  by  shift 
functions  in  the  "user  readable  comment"  emd  "user  visible  name". 

The  same  restriction  as  in  6.5.4  is  applied  in  this  case . 

All  the  graphic  character  sets  which  may  be  used  in  the  attribute  "user  readable 
comments"  and  "user  visible  name"  shall  be  designated  in  the  "comments  character 
sets" . 

There  eure  no  restrictions  concerning  the  number  of  graphic  character  sets  which 
are  designated  and/or  invoked  in  the  "comments  chauracter  sets";  hence 
designation  to  the  same  G  set  overrides  the  previous  G  set. 

If  the  attribute  "comments  character  sets"  is  not  specified,  then  the  default 
defined  in  ISO  8613  is  assumed. 


6.7.4.3    Alternative  representation  character  seta 

This  attribute  specifies  the  graphic  character  sets  designated  and  invoked  at 
the  beginning  of  the  attribute  "alternative  representation"  other  than  the 
standard  default  graphic  character  sets. 

The  restriction  on  profile  character  sets  described  in  6.7.4.1  is  also  applied. 
If  this  attribute  is  not  explicitly  specified  in  the  document  profile,  the 
default  defined  in  ISO  8613  is  assumed. 


6.7.5    Fonts  list. 

This  information  specifies  all  the  fonts  (if  any)  used  in  the  document.  It  is 
specified  using  the  attribute  "fonts  list".     (See  ANNEX  B.2). 
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6.7.6    Docunent  management  attributes 

Document  management  attributes  contain  information  about  the  content  of  the 
document  and  its  purpose.  Information  relating  to  the  following  may  be 
specified: 

-  document  description  ( see  note ) ; 

-  dates  and  times; 

-  originators; 

-  other  user  information; 

-  external  references; 
local  file  references; 

-  content  attributes;  . 

-  security  information. 

The  attributes  that  may  be  used  to  specify  this  information  are  defined  in  [ISO 
8613-4(CCITT  Recommendation  T.414]. 

The  string  of  characters  used  in  the  document  management  attributes  shall  belong 
to  the  character  sets  indicated  in  the  document  profile  attribute  "profile 
character  sets"  (see  6.7.4.1).  If  the  latter  attribute  is  not  explicitly 
specified  in  the  document  profile,  then  the  default  chaoracter  set  is  the  minimum 
subrepertoire  of  ISO  6937-2. 

The  control  functions  SP,  CR  and  LF  may  also  be  used  within  the  character 
strings  but  no  other  control  functions  are  allowed.  Hence  the  graphic  character 
set  cannot  be  changed  in  the  document  management  attributes. 

NOTE  -  The  document  description  includes  the  specification  of  the  document 
reference  (see  6.7.2.6). 
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7    Specifica'tion  o£  constituex&l;  constraints 

This  clause  specifies  the  definition  of  the  constituent  constraints  which  may  be 
represented  by  data  streams  conforming  to  this  profile. 


7.1  Introduction 

The  structure  diagrams  illustrating  the  relationships  between  the  constituents 
in  the  logical  structures  are  shown  in  7.1.1.    The  macros  indicated  on  these 
diagrams  are  defined  in  7.3.1.  These  macros  define  the  permissible  values  for 
the  attribute  "generator  for  subordinates"  that  are  applicable  to  the 
constituents  and,  in  effect,  define  the  allowed  structures  that  are  supported  by 
this  profile. 

The  structure  diagrams  illustrating  the  layout  structures  are  shown  in  7.1.2. 
The  macros  indicated  in  these  diagrams  are  defined  in  7.4.1. 
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7.1.1  Diagrams  of  relationships  of  logical  constituents 


Figure  13:  The  'body'  part  of  the  generic  logical  stinicture 
-  the  passage  and  numbered  segment  levels 


Figure  14:  The  'body  part  of  the  generic  logical 
structure  -  the  paragraph  level 
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Figure  15:  The  'eonmoQ'  part  of  the  generic  logical  structure 
7.1.2  Diagraiae  of  relationships  of  layout  constituents 


Figure  16  s  The  layout  structure  -  document  root  and  page  sets 
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Figure  17:  The  layout  structure  -  the  page  structure 


Figure  18:  The  layout  structure  -  the  header  and    footer  frame  structure 
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7.1.3  Notation 

This  clause  is  vnritten  in  accordance  with  the  Document  Application  Profile 
Proforma  and  Notation  (DAPPN)  of  ISO  8613-1,  Annex  F.    The  following 
clarifications  and  minor  extensions  apply: 

1)  (Clarification] 

The  value  range  definition  for  the  attributes  "subordinates"  and  "imaging 
order"  specify  the  set  of  object  instemces  that  may  occur.    The  ordering 
and  number  (which  may  be  zero)  of  object  instances  for  the  attribute 
"subordinates"  shall  be  in  accordzmce  with  the  value  of  the  attribute 
"generator  for  subordinates"  in  the  respective  object  class. 

2)  [Clarification] 

The  value  "ANY_STRING"  may  include  code  extension  control  functions  as  well 
as  graphic  characters. 

3)  [Extension]  . 

In  order  to  write  the  specification  of  the  usage  of  character  sets  and  code 
extension  control  functions  precisely,  the  following  extensions  are 
applied: 

a)  Following  symbols  are  introduced  to  denote  shift  functions: 


symbol 

Shift  function 

coded  representation 

LSO 

Locking  shift  zero 

00/15 

LSIR 

Locking  shift  one  right 

ESC  07/14 

LS2R 

Locking  shift  two  right 

ESC  07/13 

LS3R 

Locking  shift  three  right 

ESC  07/12 

SS2 

single  shift  two 

08/14 

SS3 

single  shift  three 

08/15 

b)  <escape-8equence>  is  extended  to  include  shift  functions: 

<escape-sequence>:  :«'ESC'<octet>. . .  [<invocation-control-function>] ; 
<invocation-control-function>:  :«'LSO'  |  'LSIR'  |  'LS2R'  |  'LS3R'  |  'SS2'  |  'SS3'; 

c)  Data  type  specification  for  #ESC  in  content  information  is  extended  as: 

<escape-sequence>. . . 
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7.2  Document  profile  constituent  constraints 
7.2.1    Macro  definitions 


DEFINE (FC,     "ASN.1{2  8  2  6  0}"  —  formatted  character  content  — ) 
DEFINE(PC,     *'ASN.1{2  8  2  6  1}"  —  processable  character  content  — ) 
DEFINE(FPC,  "ASN.1{2  8  2  6  2}"  —  formatted  processable  character  content  — ) 
DEFINE (FPR,  •'ASN.1{2  8  2  7  2}"  —  formatted  processable  raster 

graphics  content  — ) 
DEFINE (FPG,  "ASN.1{2  8  2  8  0}"  —  formatted  processable  geometric 

graphics  content  — ) 

"{'formatted'}") 
"{ 'processedale'}") 

" { ' f ormatted-processable ' } " ) 
"DocumentProf ile  (Document-architecture-class)") 


DEFINE  (FDA, 
DEFINE (PDA, 
DEFINE  (FPDA, 
DEFINE (DAC, 


DEFINE (NominalPageSizes,  " 

REQ  #horizontal-dimension  {7015}, 

REQ  #vertical -dimension  {9920} 
I REQ  #horizontal -dimension  {9920}, 

REQ  #vertical -dimension  {7015} 
I REQ  thorizontal-dimension  {9920}, 

REQ  fvertical-dimension  {14030} 
|req  fhorizontal-dimension  {14030}, 

REQ  fvertical -dimension  {9920} 
I REQ  fhorizontal-dimension  {14030}, 

REQ  #vertical-dimension  {19840} 
|r£Q  thorizontal-dimension  {19840}, 

REQ  fvertical-dimension  {14030} 
I REQ  fhorizontal-dimension  {12141}, 

REQ  fvertical-dimension  {17196} 
|req  fhorizontal-dimension  {17196}, 

REQ  fvertical-dimension  {12141} 
(req  fhorizontal-dimension  {8598}, 

REQ  fvertical-dimension  {12141} 
I REQ  fhorizontal-dimension  { 12141} < 

REQ  fvertical-dimension  {8598} 
(req  fhorizontal-dimension  {10200}, 

REQ  fvertical-dimension  {16800} 
jREQ  fhorizontal-dimension  {16800}, 

REQ  fvertical-dimension  {10200} 
|req  fhorizontal-dimension  {10200}, 

REQ  fvertical-dimension  {13200} 
|req  fhorizontal-dimension  {13200}, 

REQ  fvertical-dimension  {10200} 
|req  fhorizontal-dimension  {13200}, 

REQ  fvertical-dimension  {20400} 
jREQ  fhorizontal-dimension  {20400}, 

REQ  fvertical-dimension  {13200} 
") 


—  ISO  A5  portrait — 


-  ISO 

A5 

landscape- 

-  ISO 

A4 

portrait — 

-  ISO 

A4 

landscape- 

-  ISO 

A3 

portrait— 

-  ISO 

A3 

landscape- 

-  JIS 

B4 

( Japanese 

legal) 

portrait- 

-  JIS 

B4 

(Japanese 

legal ) 

landscape — 

-  JIS 

B5 

( Japemese 

letter) 

portrait — 

—  JIS 

B5 

(Japanese 

letter) 

landscape — 

—  ANSI  legal  portrait — 

—  ANSI  legal  lamdscape— 
—  ANSI -A  portrait — 

—  ANSI-A  landscape — 

—  ANSI-B  portrait — 

—  ANSI-B  landscape — 
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DEFINE (GRAPBZCRENDITIONS, " 

{ 'cancel' I 'increased-intensity 

'italicised' | 'underlined' j 'crossed-out' 
'primary-font' | 'first-alternative-font' 
'second-alternative-font'  'third-alternative-font' 
' fourth-alternative -font '  ' fifth-alternative-font ' 
'sixth-alternative -font' | 'seventh-alternative-font' 
'eighth-alternative-font' j 'ninth-alternative-font' 
'doubly -under lined' j 'normal-intensity 
'not-italicised' | 'not -under lined' j 'not-crossed-out'} . . . 
") 


—  Macro  defining  permissible  code  extension  announcers. 

Note  that  all  the  values  are  basic.  — 

DEFINE (COEXTEN,   •*     ESC  02/00  05/00,  —  LSO  — 

[ESC  02/00  05/03],  —  LSRl  — 

(ESC  02/00  05/05],  —  LSR2  — 

[ESC  02/00  05/07],  —  LSR3  — 

[ESC  02/00  05/10],  —  SS2  — 

[ESC  02/00  05/11]  —  SS3  — 
") 


—  Macro  defining  code  extension  announcers  for  profile  default  values  — 


DEFINE ( DAP-DEFAULT-CDEXTEN ,   " §CDEXTEN" ) 


— ■  Macros  defining  final  character  for  designation  — 


DEFINE (FCORE, 
DEFINE (F6 46, 
DEFINE (F94S, 


DEFINE (F94M, 


"04/02  —  A  final  character  designating  IS0-IR6 

(the  IRV  of  ISO  646  revised  1991,  i.e  ASCII)  — ") 

" —  a  final  character  designating  any  version  of  ISO  646 
except,  ISO-IR6  — ") 

-  a  final  character  designating  any  registered  94  single 
byte  graphic  character  set  optionally  preceded  by  one  or 
more  intermediate  cheuracters  as  defined  in  Annex  C  of 
ISO  2022 — ") 

"—a  final  character  designating  any  registered  94  multi 
byte  graphic  character  set  optionally  preceded  by  one  or 
more  intermediate  characters  as  defined  in  Annex  c  of 
ISO  2022 — ") 


DEFINE (F96S,      " —  a  final  character  designating  any  registered  96  single 

byte  graphic  character  set  optionally  preceded  by  one  or 
more  intermediate  chzuracters  as  defined  in  Annex  C  of 
ISO  2022—-) 
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DEFINE (F96M, 


' —  a  final  character  designating  any  registered  96  multi 
byte  graphic  character  set  optionally  preceded  by  one  or 
more  intermediate  characters  as  defined  in  Annex  C  of 
ISO  2022  — ") 


DEFINE (FEMPTY,  "07/14    —  the  empty  set  — ") 

—  Macros  defining  a  Revision  Number  of  a  character  set  — 

DEFINE  (REV,  ** —  An  octet  between  04/00  and  07/14  which  represents  a 
revision  number  as  defined  in  ISO2022  — ") 

—  Macros  defining  designation  sequences  — 


DEF INE ( DEG-CORE -G  0 , 


DEFINE ( DEG-6  4  6 -GO , 


"ESC  02/08  $FCORE") 

—  Designate  the  94  characters  of  IS0-IR6  (the  IRV  of 
ISO  646  revised  1991)  to  GO  — 

"ESC  02/08  $F646") 

—  Designate  any  version  of  ISO  646,  except  ISO-IR6, 
to  GO  — 


DEFINE ( DEG-ANY-Gl , 


'{  ESC  02/06  REV]   {ESC  02/09  $F94S 
ESC  02/04  02/09  $F94M 
ESC  02/13  $F96S 
ESC  02/04  02/13  $F96M]}}") 
—  Designate  any  character  set  to  Gl 


DEFINE ( DEG-ANY-G2 , 


DEFINE ( DEG-ANY-G3 , 


'{  ESC  02/06  REV]   {ESC  02/10  $F94S 
ESC  02/04  02/10  $F94M 
ESC  02/14  $F96S 
ESC  02/04  02/14  $F96M]}}") 

—  Designate  emy  character  set  to  G2 

'{  ESC  02/06  REV]   {ESC  02/11  $F94S 
ESC  02/04  02/11  $F94M 
ESC  02/15  $F96S 
ESC  02/04  02/15  $F96M]}}") 

—  Designate  any  character  set  to  G3 


DEFINE (DEG-EMPTY-Gl,   "ESC  02/09  $FEMPTY") 

—  Designate  the  empty  set  to  Gl  — 
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—  Macro  defining  permissible  graphic  character  sets.  — 

DEFINE (PERMIT-GRCHAR,     "     {$DEG-CORE-G0  $-LSO 

|$DEG-646-G0  $-LSO), 
{{$DEG-ANY-G1  $-LSlR 
$DEG-ANY-G2  $-LS2R 
$DEG-ANY-G3  $-LS3R} . . . 
I $DEG-EMPTy-Gl  $-LSlR}  ") 

—  Macro  defining  graphic  character  sets  for  DAP  defaults  — 
DEFINE ( DAP -DEFAULT-GRCHAR,    -$PERMIT-GRCHAR" ) 

—  Macro  defining  basic  character  sets.  Note  that  this  macro  is  defined 
for  clarification  of  the  specification  and  is  not  used  in  any 
other  part  of  this  DAP  specification.  — 

DEFINE (BASIC-GRCHAR,    "     $DEG-CORE-GO  $CF-LS0, 

SDEG-EMPTY-Gl  $CF-LSlR  ") 

—  Macro  defining  non-basic  graphic  character  sets  — 

DEFINE (NON-BASIC-GRCHAR,      "  {$DEG-646-G0 

$DEG-ANY-G1 
$DEG-ANY-G2 
$DEG-ANy-G3}...  ") 

—  Macro  defining  character  sets  used  in  docvunent  profile  attributes  — 

DEFINE (PROFCHAR,  " 
ESC  02/00  04/03  —  announcement  of  use  of  GO  and  Gl,  and 

invocation  into  GL  and  GR  respectively,  (no  shift 

function  are  necesseury)  — 
{$DEG-CORE-G0|$DEG-646-G0}     —  designate  GO  — 
{SDEG-ANY-Gl|$DEG-EMPTY-Gl}  —  designate  Gl  — 

--  Macro  defining  comments  ch2u:acter  sets  — 

DEFINE ( COMCHAR, " 
—  in  the  case  to  use  both  GL  and  GR  without  shift  functions  — 
ESC  02/00  04/03  —  announcement  of  use  of  GO  and  Gl,  and 

invocation  into  GL  and  GR  respectively,  (no  shift 
functions  are  necessary.)  — 
{SDEG-CORE-G0|$DEG-646-G0}    —  designate  GO  — 
{$DEG-ANY-Gl|$DEG-EMPTY-Gl>  —  designate  Gl  — 

in  the  case  of  use  of  various  character  sets  (shift  functions  are 
necessary)  — 

{ESC  02/00  05/00,  —  announcement  to  use  GO  and  LSO  — 

[ESC  02/00  05/03],  —  announcement  to  use  Gl  and  LSlR  — 

(ESC  02/00  05/05],  —  announcement  to  use  G2  and  LS2R  — 

(ESC  02/00  05/07],  —  announcement  to  use  G3  and  LS3R  — 

[ESC  02/00  05/10],  —  announcement  to  use  G2  and  SS2  — 

[ESC  02/0005/11]  }             —  announcement  to  use  G3  and  SS3  — 

{$DEG-CORE-G0 I $DEG-646-G0}     —  designate  GO  — 
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{$DE6-ANY-G1  —  designate  Gl  — 

$DE6-AMy-G2  —  designate  G2  — 

$DEG-ANY-G3} . . .  —  designate  G3  — 

$DEG-EMPTY-G1} 

—  Macro  defining  character  sets  used  for  alternative  representation  — 
OEFIME(ALTCHAR,  "$PROFCHAR") 

7.2.2    Constituent  constraints 


7.2.2.1    DocunentProfile  { 
CASE  $DAC  OF  { 


$FDA:       PERM    Generic-layout-structure  {'factor-set'}, 
PERM    specific-layout-structure  {'present'}, 

—  shall  be  present  in  the  case  of  complete  document  — 

—  and  shall  not  be  present  in  the  case  of  generic  dociiment  — 
PERM    Presentation-styles  {'present'} 

$PDA:       PERM    Generic-layout-structure  {'complete-generator-set'}, 
PERM    Generic-logical-structure      {'complete-generator  -set 

I  partial-generator-set '} , 

—  shall  be  present  if  there  is  no  external  document  class 
reference  — 

PERM    specif ic -logical-structure    { 'present ' } , 

—  shall  be  present  in  the  case  of  complete  document  — 

--  and  shall  not  be  present  in  the  case  of  generic  document  — 
PERM    Presentation-Styles  {'present'}, 
PERM    Layout-styles  {'present'} 

$FPOA:      PERM    Generic -layout-structure  {'complete-generator-set'}, 

—  shall  be  present  if  there  is  no  external  doctiment  class 
reference  — 

PERM    Specific-layout-structure  {'present'}, 

—  shall  be  present  in  the  case  of  complete  document  — 

~  and  shall  not  be  present  in  the  case  of  generic  document  — 
PERM    Generic-logical-structure  {'complete-generator-set'}, 

—  shall  be  present  if  there  is  no  external  document  class 
reference  — 

PERM    Specific-logical-structure  {'present'}, 

—  shall  be  present  in  the  case  of  complete  document  — 

—  and  shall  not  be  present  in  the  case  of  generic  document  — 
PERM    Presentation-styles  { 'present ' } , 

PERM    Layout-styles  {'present'} 

} 

PERM  External-document -class  {ANy_VALUE}, 
PERM    Resource-document  {ANY_VALUE}, 
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PERM    Resources  {MUL{R£Q  fresoxirce-identif ier  {ANY_VALUE}, 

REQ  #resource-object-class-identi£ier 

{ANY_VALUE>}}, 


—    docxunent  characteristics  — 
REQ  Document-application-profile 


{ — see  clause  8  for  a  definition  of 
the  permitted  values  for  this 
attribute — }, 


PERM    Docunent-application-profile-def aults  { 


CASE  $DAC  OF  { 

$FDA     : {PERM 
$PDA     : {PERM 
$FPDA  :{PERM 
}r 

PERM  idimensions 


PERM  #xnedium-type 


#content-architecture-class     { $FC | $FPC} } 
#content-architecture-claas     {$FC  $Pc|$FPC}} 
#content-architecture-clasa     {$FC  $FPC}} 


{REQ  thorizontal-dimension 

{REQ  tfixed-dimension  '{<=14030}}, 
REQ  ivertical-dimension 

{REQ  # fixed-dimension  {<=19840} 

—  up  to  ISO  A3  portrait  — 
I {REQ  thorizontal-dimension 

{REQ  #fixed-dimension  {<=19840}}, 
REQ  #vertical-dimension 

{REQ  #fixed-dimension  {<=14030} 

—  up  to  ISO  A3  landscape  — 
I {REQ  #horizontal-dimension 

{REQ  # fixed-dimension  {<=13200}}, 
REQ  ivertical-dimension 

{REQ  #f ixed-dimension  {<=20400} 

—  up  to  ANSI-B  portrait  — 
I {REQ  thorizontal-dimension 

{REQ  tf ixed-dimension  {<=20400}}, 
REQ  ivertical-dimension 

{REQ  if ixed-dimension  {<=13200}}} 

—  up  to  ANSI-B  landscape  — }, 

{PERM  inominal-page-size { $NominalPageSizes } , 
PERM  iside-of -sheet  {ANY__VALUE}  } , 


PERM    tpage-position  {ANY_VALUE}, 

PERM    ilayout-path         {'0-degrees' | '180-degrees' | '270-degrees'}, 


PERM    ttype-of -coding    {ASN.1{2  8  3  6  0} 

ASN.1{2  8  3  7  0} 

ASN.1{2  8  3  7  1} 

|asN.1{2  8  3  7  2} 


character  encoding  — 
T.6  encoding  — 
T.4  one  dimensional 

encoding  — 
T.4  two  dimensional 

encoding 


82 


F0026  Part  1  -  Document:  Application  Profile 


July  1992 


ASN.1{2  8  3  7  3}  —  bitmap  encoding  — 
ASN.1{2  8  3  8  0}  —  geometric  encoding  — ), 


PERM  fcharacter-content -defaults  { 


PERM 

talignment 

{ ANY_yALUE } , 

PERM 

fchsiracter-fonts 

{ ANY_VALUE } / 

PERM 

#ch«a:acter-path 

{ ANY_VALUE } , 

PERM 

#ch2u:acter-spacing 

{ ANY_yALUE } , 

PERM 

tcheuracter-orientation 

{ 'O-degrees ' 

1 ' 9  0 -degrees ' } , 

PERM 

fcode-extension-announcers 

{ $DAP-DEFAuLT-CDEXTEN} , 

PERM 

fiirst-lxne-otzset 

{ANY_VAIjUE)  / 

PERM 

#graphic-character-sets 

PERM 

#graphic~chaxacter**subrepertoire 

PERM 

#  graphic -rendition 

{ 9GRAPHXCR£NuXTXONS } ^ 

PERM 

tindentation 

{ANY_VAl»Ufi}  f 

PERM 

ffinitxal-ozzset 

{ ANy__VAijUB  }  , 

P£KH 

fitemisation 

PERM 

#kerning-of f set 

{ANY_VALUE}, 

PERM 

#line-layout -table 

{ANY_VALUE}, 

PERM 

#line-progression 

{ANY__VALUE}  , 

PERM 

tline-spacing 

{ANY_VALUE}, 

PERM 

foxrphan-size 

{ANy_VALUE} , 

PERM 

tproportional-line-spacing 

{ANY_VALUE}, 

PERM 

#widow-size 

{ANY_VALUE}}, 

PERM  #raster-graphic-content-def aults  { 
PERM  #c lipping 
PERM  # image -dimensions 
PERM  #pel-spacing 
PERM  #spacing-ratio 
PERM  Icompression 


A1IY_VALUE}, 
ANY_VALUE}, 
ANY_VALUE}, 
ANY_VALUE}, 
ANY_VALUE}}}, 


REQ  Document-architecture-class 
REQ  Content-architecture-classes 
REQ  Interchange-format 


{$FDA|$PDa|$FPDA}, 
{[$FCi,($Pci,[$FPC],[$rPRl/ 


REQ  Oda-version 


—  See  clause  8  for  a  defintion  of 

the  permitted  values  for  this  profile 

{REQ  #standard-or-recommendation{"ISO  8613"}, 
REQ  #publication-date{ 1992-05-01}}, 


—  non  basic  document  characteristics  — 
PERM    Profile-character-sets  {$PROFCHAR}, 
PERM    Comments -character-sets  {$COMCHAR}, 
PERM    Alternative-representation-cheuracter-sets  {$ALTCHAR} 
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PERM    Page-dimensions  {PMUL 

«  (REQ  thorizontal-dimension 

{REQ  # fixed-dimension  {<«14030}}, 
REQ  ivertical-dimension 
{REQ  # fixed-dimension  {12401. .19840}} 
I {REQ  ihorizontal -dimension 

{REQ  #fixed-dimension  {9241. .14030}}, 
REQ  ivertical-dimension 
{REQ  ffixed-dimension  {019840} } 
—  Up  to  ISO  A3  portrait  — 

I {REQ  thorizontal-dimension 

{REQ  ffixed-dimension  {12401. .19840}}, 
REQ  ivertical-dimension 
{REQ  ifixed-dimension  {<>14030}} 
I {REQ  ihorizontal-dimension 

{REQ  ifixed-dimension  {<«19840}}, 
REQ  ivertical-dimension 
{REQ  ifixed-dimension  {9241. . 14030}} 

—  up  to  ISO  A3  landscape  — 

I {REQ  ihorizontal-dimension 

{REQ  ifixed-dimension  {<»13200}}, 
REQ  ivertical-dimension 
{REQ  ifixed-dimension  {12401. .20400}} 
I {REQ  ihorizontal-dimension 

{REQ  ifixed-dimension  {9241. .13200}}, 
REQ  ivertical-dimension 
{REQ  ifixed-dimension  {<«20400}} 

—  up  to  ANSI-B  portrait  — 

I {REQ  ihorizontal-dimension 

{REQ  ifixed-dimension  {12401. .20400}}, 
REQ  ivertical-dimension 
{REQ  ifixed-dimension  {<«13200}} 
'        ^  I {REQ  ihorizontal-dimension 

{REQ  ifixed-dimension  {<'20400}}, 
,  REQ  ivertical-dimension 

{REQ  ifixed-dimension  {9241.  .13200}}  } 

—  up  to  ANSI-B  landscape  —  }, 

—  any  value  of  dimensions  which  is  greater  than  the  common  assured 
reproduction  area  of  iso  A4  and  ANSI -A  is  non-basic  — 

PERM    Medium-types  {PMUL 

{PERM  inominal-page-size{$NominalPageSize8}, 
PERM  iside-of-sheet{ 'recto' j 'verso'}}}, 
—  all  values  of  "medium  type"  are  non-basic  — 

PERM    Layout-paths        {{'0-degrees' | '90-degrees' | '180-degrees'}. . .}, 

PERM    Borders  {ANY_VALUE}, 

PERM    Coding-attributes  { 
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PERM    #ra3ter-graphica-coding-attributes  { 
PERM  tcompression 


{ 'uncompressed' } } } , 


PERM    Presentation-features  { 

PERM  tcharacter-presentation-features 
PERM  #character-orientation 
PMUL  {PERM  #character-path 


PMUL  {PERM  tcharacter-spacing 


{ 


{ '90-degrees'>, 
{ '90-degrees ' 
180-degrees' 
270-degrees'}}, 

{<100| 100| 160|200}}, 
-only  values  <100  are  required 
to  be  specified.    Values  100,  160 
200  may  be  specified  here  for 
upwcurds  compatibility  from  FODll— 


PMUL  {PERM  #graphic-character-sets  {$NON-BASIC-GRCHAR) } , 
PMUL  {PERM  #graphic-character- 

subrepertoire  {ANY_VALUE>} , 

PMUL  {PERM  #graphic-rendition  { 'cross^d-out' 

I ' not-cros  sed-out ' } } , 
—  values  need  not  be  decleured.    Only  permitted  for  upwards 

compatability  from  FODll  — 
PMUL  {PERM  iline-spacing 


{ANY_VALUE) 
EXCEPT{200,300,400}, 


—  value  150  need  not  be 

decleured,  the  value  may  be 
specified  here  for  upwards 
compatability  from  FODll  — 


PERM  # line-progression 


{ '90-degrees ' }} , 


PERM  #raster-graphics-presentation-features  { 
PMUL  {PERM  #pel-spacing  {ANY_VALUE) 

EXCEPT { 1 6 , 12 , 8 , 6 , 5 , 4 , 3 , 2 , 1 } , 

—  Any  value  of  #pel  spaces  is  permitted  as  basic  — 

—  Basic  values  of  flength  are  multiples  of  #pel  spaces  as  listed  — 


—  additional  document  characteristics  — 


PERM    Fonts -list 


{PMUL{REQ  #font-identifier  {ANY_VALUE}, 
REQ  ifont -reference  {ANY_VALUE})}, 


—  document  management  attributes  — { 


—  document  -description 

PERM  Title 

PERM  Subject 

PERM  Document -type 

PERM  Abstract 

PERM  Keywords 

REQ  Document -reference 


{ANY_STRING} , 
{ANY_STRING} , 
{ANY_STRING} , 
{ANY_STRING}, 
{ANy_STRING.  . 
{ANY_VALUE}, 


}, 
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dates  and  times  — > 

PEIUl  Document ->date-and-tiffle 

PERM  Creation-date -and-time 

PERM  Local-filing-date-and-time 

PERM  Expiry -date -and -time 

PERM  start-date-and-time 

PERM  Purge -date -and-time 

PERM  Release-date-and-time 

PERM  Revision-history 

—  originators  — 
PERM  Organizations 
PERM  Preparers 
PERM  Owners 

PERM  Authors 

—  other  user  information  -- 

PERM  Copyright 

PERM  status 

PERM  User-specific-codes 

PERM  Distribution-list 

PERM  Additional-information 


{AHy_STRING)  , 
{ANY_VALUE), 
{ANy__STRING}  , 

{any~strihg>  , 
{any~string> , 
{any~string> , 
{ahy~string> , 
(any'value). 


{AMT_STRIMG...}, 

{ANY~VALUE}, 

{ANY_VALUE}, 

{KtrTyKLaE}, 


{ANY_VALUE}, 
{ANY_STRING> , 
{ANy~STRING.. 
{ANy__VALUE}, 
<ANY_VALUE}, 


—  external  references  — 
PERM  References-to-other-documents 
PERM  superseded-documents 


{ANY__VALUE}, 
{ANY^VALUE), 


—  local  file  references  — 
PERM  Local-file-references 

content  attributes  — 
PERM  Document-size 
PERM  Huffiber-of-pages 
PERM  Languages 

security  infojrmation  ~ 
PERM  Authorization 
PERM  Security-classification 
PERM    Access -rights 


{ANY_VALUE}, 


{ANY_INTEGER>  , 
{ANY~INTEGER) , 
{ANY~STRING...}# 


{any^value) , 
{any'strikg} , 
{any__string.  . 


>} 


7.3  Logical  constituent  constraints 
7.3.1    Macro  definitions 


DEFINE ( DOCLogRootGFS , 
<con8truction-expr> 


<construction-term> 


: :«  <construction-term> 
I <construction-type>; 


<construction-f actor> 
OPT  <construction-factor> 
REP  <construction-f actor> 
OPT  REP  <con8truction-factor>; 


FOD26  Part  1  -  Docunent  Application  Profil* 


July  1992 


<construction-typ«> 


<construction-£actor> 


SEQ{  {<construction-ten[i>}  . . . ) 
I CHO( {<con8truction-tenn>} . . . ) ; 

OBJECT_CIASS_ID_OF ( Passage ) 
I <con8truction-type>; 


DEFINE  (  CONSTRAZMT- 1 , 

<con0tr aint- 1> 


t <construction-term> 
1 <construction-type>; 


<construction-t«nn> 


<construction-type> 


<con8truction-factor> 


: :«  <construction-factor> 

OPT  <con8truction-f actor> 
REP  <construction-f actor> 
OPT  REP  <cons true tion-fac tor >; 

SEQ( {<construction-tenn>} . . . ) 
I CHO( {<construction-tenn>} . . . ) » 

OBJECT_CLASS_ID_OF  ( Peir  agr  aph ) 
OB JECT_CIASS_ID_OF ( BodyText ) 
OBJECT_CLASS_ID_OF ( BodyRaster ) 
OB JECT_CLASS_ID_OF ( BodyGeometr Ic ) 
<cons true tion-type> ; 


DEFINE ( CONSTRAINT-2 , 

<con8traint-2> 


OB  JECT_CLASS_ID_OF  ( NumberedSegment ) 
OPT  REP  OBJECT_CLASS_ID_OF( NumberedSegment) 
REP  OB JECT_CLASS_ID_OF  ( NumberedSegment ) 
OPT  OBJECT  CLASS  ID  OF ( NumberedSegment ) ; 


DEFINE (Pas 8 ageGFS,  * 
<coastruction-ttxpr> 


$C0NSTRAINT-1 
$C0NSTRAINT-2 


) 


:;«  <eon9traint-l> 
<eonstraint-2> 

SEQ ( <eonstraint-lxconstraint-2> ) ; 


DEFINE ( NumberedSegmentGFS , 
<conatruction-expr> 


<con8traint-3> 


$CONSTRAINT-l 
$C0NSTRAINT-2 


SEQ(<eonstraint-3>[<eonstraint-l>] 
(<eonstraint-2>] ) ; 

OBJECT_CLASS_ID_OF( Number) ; 


DEFINE ( Paragr aphGFS , 
<construction-expr> 


: :=  <eonstruetion-term> 
I <eonstruetion-type>; 
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<construction-tenn> 


: j»  <con8truction-factor> 

OPT  <construction-factor> 
REP  <con8truction-f actor> 
OPT  REP  <construction-factor>; 


<const]niction-type> 


ts>  SEQ( {<construction-tenn>} . . . ) 
I CBO( {<construction-tenn>} . . . ) # 


<con8truction-£actor> 


t:»  OBJECT_CIASS_ID_OF(BodyText) 

OB  JECT__CLASS_ID_OF  ( BodyRaster ) 
OB JECT_CIASS_ID_OF ( BodyGeometr ic ) 
OB  JECT__CLASS_ID_OF  ( Footnote ) 
<con8truction-type> ; 


DEFINE ( FootnoteGFS , 
<construction-expr> 


) 


: »  SEQ ( OB JECT_CLASS_ID_OF ( FootnoteRef erence ) 
OBJECT_CLASS_lD_OF(FootnoteBody) ) ; 


DEFINE ( FootnoteBodyGFS , 
<con8txniction-expr> 


J  :■  SEQ(OBJECT_CLASS_ID__OF(FootnoteNuinber 

<constraint-4>) ; 


<con8traint-4> 


OB JECT_CLASS_ID_OF ( FOOtnoteText ) 
REP  ( OB JECT_CLASS__ID_OF  ( FOOtnoteText )  ) 
CHO( {OBJECT_CLASS_ID_OF( FOOtnoteText) } . . . ) 
REP  CHO  (  {OBJECT_CLASS_ID__OF  ( FOOtnoteText )  ) 


); 


DEFINE  ( CoinmonContentGFS ,  ** 

<con8truction-expr>  : <con8truction-factor> 

|sEQ(<con8truction-£actor>. . . ) ; 

<construction-factor>         :  OBJECT__CIiASS_ID_0F(CoinmonText) 

OB  JECT_CLASS__ID_OF  ( PageNumber ) 
OBJECT__CLASS_ID_OF  ( CommonRaster ) 
OBJECT_CLASS_ID__OF(CoinmonGeoinetric) ; 

") 

DEFINE (N, 

-<n>::-{«-0""|-n--|-"2--|--3"-|--4--|««5«-|-«6--|--7--|--8"-|-«9--}...;-) 
—  any  atring  of  characters  from  the  set  of  characters:  '0',.»'9'  — ; 

—  Defines  the  prefix  binding.    This  binding  may  be  used  to  associate  a  string 
literal  with  an  object  or  object  class.    In  addition,  this  binding  is  used  to 
prefix  text  to  another  binding,  such  as  a  segment  number,  footnote  number  or 
page  number.    The  instances  are  differentiated  by  a  suffix  number.  — 

") 
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DEFINE (PREFIX, 

<prefix>      ::«    ""pref  ix-''"<n>; 
$N 

-) 

—  Defines  the  suffix  binding.    This  binding  nay  be  used  to  associate  a  string 
literal  with  an  object  or  object  class.    In  addition,  this  binding  is  used  to 
suffix  text  to  another  binding,  such  as  a  segment  number,  footnote  number  or 
page  number ^    The  instances  are  differentiated  by  a  suffix  number.  — 

DEFINE (SUFFIX, 

<8Uffix>      ::■    " "suffix-" "<n>; 
$N 

") 

—  Defines  the  separator  binding.  This  binding  is  used  to  provide  a  separator 
character  for  a  hierarchical  form  of  a  segment  number,  footnote  number  or  page 
number.    The  instances  are  differentiated  by  a  suffix  number.  — 

* 

DEFINE ( SEPARATOR, 

<separator>  ::■  "8eparator-"<n>; 

$N 

") 

—  Defines  the  general  number  binding.    This  binding  may  be  instanced  for  use 
as  the  numeric  value  for  use  such  as  in  segment  nximber,  footnote  number  or  page 
number  bindings.    The  instances  are  differentiated  by  a  suffix  number.  — 

DEFINE (NUMBER, 

<number>        ::»    " "number-" "<n>; 
$N 

") 

~  Defines  the  general  number  string  binding.    This  binding  may  be  instanced 
for  use  as  the  string  value  such  as  for  segment  number,  footnote  number  or  page 
numbers.    The  instances  are  differentiated  by  a  suffix  number.  — 

DEFINE ( NUMBERSTRIN6 ,  " 

<number8tring>  ::■  "" number string-""<n>; 

SN 

") 


—  Used  to  initialise/specify  any  of  the  bindings,    the  bindings  defined  by 
this  macro  are  permitted  to: 

-  any  logical  object  class 

-  any  logical  object 

-  any  layout  object  class  except  frame  classes  and  block  classes,  and 

<•  any  layout  object  except  frames  and  blocks  in  the  case  of  FPDA  and  FDA.  — 
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DEFINE ( INITIALISEANY, 


REQ  «binding-identi£er{$PREFIX}, 

REQ  #binding -value {ANY_STRING} 
|req  #binding-identifer{$SUFFIX}, 

REQ  #binding-value{ANY_STRING} 
I REQ  #binding-identi£er{$SEPARATOR} , 

REQ  #binding-value{ANy_STRING} 
|req  #binding-identifer{$NUMBER}, 

REQ  tbinding-value { { >= 0 } 
I REQ  #binding-identifer{$NUMBERSTRING} , 

REQ  #binding-value{ANY_STRlNG} 


—  Used  to  make  a  simple  or  compound  string  out  of  the  number  bindings.  — 


DEFINE ( USENUMBERSTRINGS , 


<hierarchic -expr > 


<simple-expr> 


REQ  #binding-identifer{$NUMBERSTRlNG} , 
REQ  #binding-value{<3tring-expr>: : =<hierarchic 
-expr>|<simple-expr>; } 

: ;=    B_REF(SUP(CURR_OBJ) ) (<numberstring>) 
+B_REF(SUP(CURR_OBJ) ) (<separator>) ) 
+<simple-expr>; 


MK-STR(B_REF(CURR-OBJ) (<number>) ) 
U-ALPHA(B_REF(CURR-OBJ) (<number>) ) 
L-ALPHA(B_REF(CURR-OBJ) (<number>) ) 
U-ROM(B__REF(CURR-OBJ)  (<number>) ) 

L-ROM(B~REF(CURR-OBJ) (<number>) ) 
MK-STR(ORD(CURR-OBJ) ) 
U-ALPHA ( ORD ( CURR-OB J ) ) 
L-ALPHA(ORD(CURR-OBJ) ) 
U-ROM ( ORD ( CURR-OB J ) ) 
L-ROM( ORD (CURR-OB J) ) ; 


$ SEPARATOR 

$NXnffiER 

> 


) 


—  Used  to  increment  any  of  the  number  bindings.  — 
DEFINE ( USENUMBERS ,  " 


REQ  #binding-identifer{$NUMBER}, 
REQ  #binding-value 

{<num-expr>:  :=INC(B_REF(PREC(CURR__OBJ) )  (<number>) ) ; 


$NUMBER} 


—  This  string  expression  is  allowed  in  a  content  generator  for  Number  to 
automatically  generate  text  for  segment  numbers.  — 
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DEFINE ( SEGMENTNUMBER , 

<string-expr>  ::=     [<pre-at>]<niim-3t>[<suf-st>] ; 

<nuin-a tr>  s :  =    B_REF  ( SUP  ( CURR_0B J ) )  ( <nuinber s tr ing> ) ; 

<pre-8t>  ; :  =    B_REF ( SUP ( CURR_OBJ ) ) ( <pref ix> ) 

|anY_STRING; 

<8Uf-st>  ::=     B_REF(SUP(CURR_OBJ) ) (<suffix>) 

|anY_STRING; 

$NUMBERSTRIMG 

$PREFIX£S 

$SUFFIX£S 

") 

—  Used  to  initialise  fnotenimber  and  fnotestring  bindings.  — 
DEFINE ( INITIALISEFNOTE , 

REQ  #binding-identif er { " " f notenumber " " ) , 

REQ  #binding-value{>=0} 

") 

—  Used  to  increment  fnotenumber  binding.  — 
DEFINE ( INCFNOTENUMBER, 

REQ  #binding-identifer{ ""fnotenumber" "} , 
REQ  #binding-value {<num-expr> : : =INC ( B_REF ( PREC 

(CURR-OBJ) ) (""fnotenumber"") ; } 

") 

—  Used  to  create  a  fnotestring  from  a  fnotenumber  binding.  — 

DEFINE ( FNOTENUMBERSTRING , 

REQ  #binding-identifer{ "fnotestring" } , 
REQ  #binding-value{<str-expr>: := 

MK-STR  ( B_REF  ( CURR-OBJ )  ( "  "  fnotenumber  "  " ) ) 

U-ALPHA(B_REF( CURR-OBJ)  (""fnotenumber"") ) 

L-ALPHA(B_REF( CURR-OBJ)  (""fnotenumber"") ) 

U-ROM ( B_REF ( CURR-OBJ ) ( " " fnotenumber " " ) ) 

L -ROM (B_REF( CURR-OBJ) (""fnotenumber"" ) ) ; } 

") 

—  Used  to  reset  the  footnote  number  string  to  a  string  literal.    This  provides 
a  mechanism  for  setting  the  footnote  number  string  to  something  other  than  a 
numeric  value.  — 

DEFINE ( FNOTESTRINGLITERAL ,  " 

REQ  #binding-identif er { " fnotestring" } , 
REQ  #binding-value{ANY_STRING} 
") 

—  This  string  expression  is  allowed  in  a  content  generator  for  FootnoteNumber 
and  FootnoteRef erence  to  automatically  generate  text  for  a  footnote  number.  — 
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DEFINE ( FNOTENUMBER, 

<string-expr>  ::»    [ANY_STRING]<nuin-atr>[ANY_STRING] ; 

<nuin-str>  : : «    B_REF  ( SUP  ( CURR__OB J ) )  ( "  "  fnotestring"  " ) 

-) 

DEFINE (PGNUMBERS  ,  " 

<8tring-expr>  j:«  [ANy__STRING]  {<nuin-8tr>}  [ANY^STRING]  ; 

<nuin-8tr>  MK-STR(<numeric-expr>) 

U-ALPHA ( <numer ic -expr> ) 
L-ALPHA  ( <nuineric-expr> ) 
U-ROM  ( <ntiiner  ic -expr  > ) 
L-ROM(<nuineric-expr>) ; 

<nuineric-exp>  :  :=  B_REF(SUP(CURR_INST(<class-or-typel>, 

(CURR_OBJ) ) ) ) ( " "PGnum" " ) 
I B_REF ( CURR_INST ( <clas s -or-type2> , 
CURR_OBJ) ))(" "PGnum" ") ; 

<clas8-or-typel>    ::=  'frame'; 

<class-or-type2>     : :=  'page' 

OB  JECT__CLASS__ID_OF  ( Page ) 

OB JECT_CLASS_ID_OF ( RectoPage ) 

OBJECT_CLASS_ID_OF ( VersoPage ) ; 

") 


7.3.2    Factor  constraints 
7.3.2.1     FACTOR  ANY-LOGICAL  { 

GENERIC : 


REQ 

Object-type 

{VIRTUAL} , 

REQ 

Object-class-identifier 

{ANY_VALUE} 

SPECIFIC : 

PERM 

Object-type 

{VIRTUAL}, 

REQ 

object-identifier 

{ANY_VALUE}, 

REQ 

Object-class 

{VIRTUAL} 

SPECIFIC_ 

AND_GENERIC: 

PERM~ 

User-re adable-c omme nt s 

{ANY_STRING} , 

PERM 

User-visible-name 

{ANY_STRING} } 

7.3.3    Constituent  constraints 

7.3.3.1    DocumentLogicalRoot:  ANY -LOGICAL  { 

GENERIC : 

REQ       Object-type  {'document-logical-root'}, 

REQ       Generator-for-subordinates    { $DocLogRootGFS } , 

REQ       Application-comments  {REQ  #constraint-name  {"0"}, 
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SPECIFIC : 

PERM  Object-type 

REQ  Object-class 

R£Q  Subordinates 

PERM  Application-comments 

SPECIFIC_AND_GENERIC : 

PERM  Bindings 


{ 'document-logical-root' } , 
{OBJECT_CLASS_ID_OF 

(DocumentLogicalRoot) } , 
{ SUB_ID_OF ( Pas  s  age )+}, 
{REQ  #constraint-name  {"O"), 
PERM  #external-data  {ANY_VALUE}} 

{PMUL{$INITIALISEANY} , 
PERM{$INITIALISEFNOTE} } ) 


7.3.3.2    Passage:  ANY -LOGICAL  { 


GENERIC: 
REQ 
REQ 
REQ 

SPECIFIC: 
'  PERM 
REQ 
REQ 


Object-type 

Generator-£or-subordinates 
Application-comments 


Object-type 

Object-class 

Subordinates 


PERM  Application-comments 

SPECIFIC_AND_GENERIC : 
PERM  Layout-style 
PERM  Bindings 


{ 'composite-logical-object ' } , 
{$PassageGFS} , 

{REQ  tconstraint-name  {"1"}, 
PERM  #external-data  {ANY_VALUE}} 

{ ' composite-logical-object ' } , 
{ OB JECT_CLASS_ID_OF (Passage ) } , 
{ SUB_ID_OF ( Number edsegment ) + , 

SUB_ID_OF ( BodyText ) + , 

SUB_ID_OF ( BodyRas ter ) + , 

SXJB_ID_OF  ( BodyGeometr  ic ) + , 

SUB_ID_OF ( Paragraph ) + } , 
{REQ  tconstraint-name  {"1"}, 

PERM  #external-data  {ANY_VALUE}} 

{STYLE_ID_OF(L-Stylel) } , 
{PMUL{$INITIALISEANY} , 
PERM{$INITIALISEFNOTE) } 


7.3.3.3    NumberedSegment:  ANY -LOGICAL  { 


GENERIC : 
REQ 
REQ 
REQ 


SPECIFIC: 
PERM 
REQ 
REQ 


Object -type 

Generator-for-subordinates 
Application-comments 


{ 'composite- logical-object ' } , 
{ $NumberedSegmentGFS } , 
{REQ  #constraint-name  {"2"}, 
PERM  #external-data  {ANY_VALUE} } , 
{PMUL{§INITIALISEANY} , 
PERM{ $USENUMBERS } , 
REQ{$USENUMBERSTRING} } 

—  The  binding  USE  NUMBERS  shall  also  be  present  if  — 

—  USENUMBERSTRING  does  not  use  the  ORD  option.  — 


REQ  Bindings 


Object-type 

object-class 

Subordinates 


{ 'composite-logical-object' } , 
{OBJECT_CLASS_ID_OF( NumberedSegment) } , 
{ SUB_ID_OF ( Number ) , 

SUB_ID_OF (NumberedSegment ) + , 

SUB_ID_OF ( BodyText ) + , 
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PERM  Bindings 

PERM  Application-comments 

SPECIFIC_AND_GENERIC  J 
PERM  Layout-Style 


SUB_ID_OF ( BodyRaster )  + , 

SUB_ID_OF ( BodyGeometric ) + , 

SUB_ID_OF( Paragraph )+} , 
{PMUL{$INITIALISEANy} } , 
{REQ  #constraint-name  {"2"}, 

PERM  #external-data  {ANY_VALUE}} 

{STYLE_ID__OF(L-Style4 ) }  > 


7.3.3.4    Number:  ANY-LOGICAL  { 


GENERIC : 
REQ 
REQ 
REQ 

SPECIFIC: 
PERM 
REQ 
PERM 


Object-type 

Content-generator 

Application-comments 


object-type 

object-class 

Application-comments 


SPECIFIC_AND_GENERIC : 
PERM  Layout-Style 
PERM  Presentation-style 
PERM      Content -architecture -class 


{ 'basic-logical-object ' } , 
{$SEGMENTNUMBER} , 
{REQ  Icons traint-name  {"3"}, 
PERM  #external-data  {ANY__VALUE} } 

{ 'basic-logical-object' } , 
{OBJECT_CLASS_ID_QF (Number) } , 
{REQ  #constraint-name  {"3"), 
PERM  #external-data  {ANY_VALUE}} 

{ STYLE_ID_OF ( L-Sty le2 ) } , 
{STYLE_ID_OF(P-Stylel ) } , 
{SFC| $PC| $FPC}} 


7.3.3,5    Paragraph:  ANY-LOGICAL  { 


GENERIC : 
REQ 
REQ 
REQ 

SPECIFIC! 
PERM 
REQ 

REQ 


Object-type 

Generator-for-subordinates 
Application-comments 


Object-type 
Object-class 

Subordinates 


PERM  Application-comments 

SPECIFIC_AND_GENERIC : 
PERM  Layout-Style 


{ 'composite-logical-object' } , 
{$ParagraphGFS} , 
{REQ  #constraint-name  {"6"), 
PERM  #external-data  {ANY_VALUE)} 

{ 'composite-logical-object' } , 
{ OB JECT_CLASS_ID_OF 

(Paragraph) } , 
{ SUB_ID_OF ( BodyText ) + , 

SUB_ID_0F ( Footnote ) + , 

SUB_ID_OF ( BodyRaster ) + , 

SUB_ID_OF ( BodyGeometric ) +} , 
{REQ  tconstraint-naune  {"6"}, 

PERM  #external-data  {ANY__VALUE} } 

{STYLE_ID_OF (L-Style4 ) } } 
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7.3.3.6    BodyText:  ANY -LOGICAL  { 


GENERIC : 
REQ 
PERM 
REQ 

SPECIFIC: 
PERM 
REQ 
PERM 


Object -type 
Resource 

Application-comments 


Object-type 

Object-class 

Application-comments 


SPECIFIC_AND_GENERIC : 
PERM  Layout-style 
PERM  Presentation-style 
PERM  Content-architecture-class 
PERM      Content -portions 


{ 'basic-logical-object ' > , 
{ANY_VALUE}, 

{REQ  #constraint-name  {"14"}, 
PERM  #external-data  {ANY_VALUE}> 

{ 'basic-logical-object' } , 
{OBJECT_CLASS_ID_OF( BodyText) } , 
{R£Q  #constraint-name  {"14"}, 
PERM  #external-data  {ANY_VALUE}} 

{STYLE_ID_OF (L-Style2 ) } , 
{STYLE_ID_OF(P-Stylel ) } , 
{$FC|$PC|$FPC}, 
{CONTENT_ID_OF( 

Character-content-portion)+} } 


—  if  the  attribute  "content  portions"  is  specified  neither  in  the 
specific  nor  in  the  generic  part  then  the  attribute  "resource" 
shall  be  specified  — 


7.3.3.7    BodyGeometric :  ANY -LOGICAL  { 


GENERIC : 
REQ 
REQ 
PERM 


SPECIFIC : 
PERM 
REQ 
PERM 
PERM 


Object-type 

Content-architecture-class 
Resource 


REQ  Application-comments 


Object-type 
Object-class 

Content-architecture-class 
Application-comments 


SPECIFIC_AND_GENERIC : 
PERM  Layout-Style 
PERM  Presentation-style 
PERM  Content-portions 


{ 'basic-logical-object ' } , 

{$FPG}, 

{ANY_VALUE}, 

{REQ  #constraint-name  {"18"}, 
PERM  #  external -data  {ANY__VALUE}  } 

{ 'basic-logical-object ' } , 

{ OB JECT_CLASS_lD_OF (BodyGeometric ) } , 

{$FPG}, 

{REQ  #constraint-name  {"18"}, 
PERM  #external-data  {ANY_VALUE}} 

{STYLE_ID_0F(L-Style5 ) } , 
{STYLE_ID_OF (P-Style2 ) } , 
{CONTENT_ID_OF ( 

Geometric -graphics -content -portion) } } 


—  if  the  attribute  "content  portions"  is  specified  neither  in  the 
specific  nor  in  the  generic  part  then  the  attribute  "resource" 
shall  be  specified  — 
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7.3.3.8    BodyRaster:  ANY -LOGICAL  { 


GENERIC : 
REQ 
KEQ 
PERM 
REQ 

SPECIFIC: 
PERM 
REQ 
PERM 
PERM 


Object -type 

Content-architecture-class 
Resource 

Application-comments 


Object-type 
Object-class 

Content-architecture-class 
Application-comments 


SPECIFIC_AND_GENERIC : 
PERM  Layout-Style 
PERM  Presentation-style 
PERM     Content -portions 


{ 'basic-logical-object ' } , 

{$FPR), 

{ANY_VALUE}, 

{REQ  #constraint-name  {"17"}, 
PERM  #external-data  {ANY__VALUE}} 

{ 'basic-logical-object' ) , 
{OBJECT_CLASS_ID_OF  ( BodyRaster ) } , 
{$FPR), 

{REQ  #constraint-name  {"17"}, 
PERM  #external-data  {ANY^VALUE}} 

{STYLE_ID_OF ( L-Style5 ) } , 
{STYLE_ID_OF ( P-Style3 ) } , 
{CONTENT_ID_OF ( 

Raster-graphijCs -content -portion) }} 


—  if  the  attribute  "content  portions"  is  specified  neither  in  the 
specific  nor  in  the  generic  part  then  the  attribute  "resource" 
Bhall  be  specified  — 


7.3.3.9     Footnote!  ANY -LOGICAL  { 


GENERIC : 
REQ 
REQ 
PERM 


SPECIFIC: 
PERM 
REQ 
REQ 

PERM 
CASE 
{REQ 


Object-type 

Generator-for-subordinates 
Bindings 


REQ  Application-comments 


{ 'composite-logical -object ' } , 
{$FootnoteGFS} , 

{  {  SINCFNOTENUMBER,  $FNOTENUMBERSTRING} 

I $FNOTESTRINGLITERAL} , 
{REQ  Icons traint-name  {"8"}, 

PERM  #external-data  {ANY__VALUE}} 


Object-type 
Object-class 
Subordinates 


Bindings 
Footnote 
Bindings 


{ 'composite-logical-object ' } , 
{OBJECT_CLASS_ID_OF  ( Footnote )}  , 
{ SUB_ID_OF ( FootnoteRef erence ) , 
SUB_ID_OF(FootnoteBody ) } , 
{$FNOTESTRINGLITERAL} , 

(GENERIC:  Bindings)  OF  VOID 

{$FNOTESTRINGLITERAL} , 


PERM  Application-comments 


SPECIFIC_AND_GENERIC  : 
PERM  Layout-Style 


{REQ  #constraint-name  {"8"}, 
PERM  #external-data  {ANY__VALUE} } 

{STYLE_ID_0F(L-=Style7 )  }  } 
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7.3.3.10    FootnoteReference:  ANY -LOGICAL  { 


GENERIC : 
REQ 
REQ 
REQ 

SPECIFIC: 
PERM 
REQ 


Object-type 

Content-generator 

Application-comments 


Object-type 
Object-class 


PERM  Application-comments 

SPECIFIC_AND_GENERIC : 
PERM  Layout-Style 
PERM  Presentation-Style 
PERM  Content-architecture-class 


{ 'basic-logical-object ' } , 
{$FNOTENUMBER} , 
{REQ  #constraint-name  {"10"}, 
PERM  #external-data  {ANY_VALUE}) 

{ 'basic-logical-object ' } , 
{ OB JECT_CLASS_ID_OF 

(FootnoteReference) } , 
{REQ  #constraint-name  {"10"}, 
PERM  #external-data  {ANY_VALUE}} 

{STYLE_ID_OF (L-Style2 ) } , 
{ STYLE_ID_OF ( P-Sty le 1 ) } , 
{SFC|$PC| $FPC}} 


7.3.3.11    FootnoteBody:  ANY -LOGICAL  { 


GENERIC : 

REQ  Object-type 

REQ  Generator-f or-subordinates 

REQ  Application-commencs 

PERM  Layout-Style 


{ 'composite-logical-object ' } , 
{$FootnoteBodyGFS} , 
{REQ  #constraint-name  {"11"}, 
PERM  #external-data  {ANY_VALUE}} 
{STYLE_ID_OF  (L-Stylell)} 


SPECIFIC: 

PERM  Object-type 

REQ  Object-class 

REQ  Subordinates 

PERM  Application-comments 

PERM  Layout-style 
} 


{ 'con^osite-logical-object ' } , 
{OBJECT_CLASS_ID_OF( FootnoteBody) } , 
{ SUB_ID_OF ( FootnoteNumber , 

SUB_ID_OF(FootnoteText)+} , 
{REQ  #constraint-name  {"11"}, 

PERM  #external-data  {ANY_VAHJE} } } 
{STYLE_ID_OF  (L-Stylell)} 


7.3.3.12    FootnoteNumber:  ANY -LOGICAL  { 


GENERIC: 
REQ 
REQ 
REQ 

REQ 

SPECIFIC: 
PERM 
REQ 
PERM 


Object -type 

Content-generator 

Application-comments 

Layout-style 


Object-type 

Object-class 

Application-comments 


PERM  Layout-style 


{ 'basic-logical-object' } , 
{$FNOTENXniBER}, 
{REQ  #constraint-name  {"9"}/ 
PERM  #external-data  {ANY_VALUE}} 
{STYLE_ID_0F(L-Style9) > 


{ 'basic-logical-object' } , 
{OBJECT_CLASS_lD_OF{ FootnoteNumber) } , 
{REQ  tconatraint-naime  {"9"} 
PERM  #external-data  {ANY_VALUE} } , 
{STYLE_ID_0F(L-Style9 ) } 
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SPECIFIC_M3D_GS!«ERIC  i 

PERM  Presentatiesi-'Styl© 

PERM  Content-arehitecture-^elasa 

7.3,3,13    FootaoteTests  i^fY-LOGICM.  { 


July  19S2 


GENERIC  S 
HEQ 
REQ 


Object-type 
Application-comments 


Layout-Style 


SPECIFICS 
PERM 

.  REQ 
REQ 

PERM 

PERM 


Object-type 

Object-class 

Content-portions 

Application-coffisnents 

Layout-style 


SPECIFIC__AND__GENERIC  J 

PERM  Presentation-Style 

PERM  Content-arehitecture-clase 

7.3.3,14 


GENERIC; 

REQ 

REQ 
REQ 

PERM 
PERM 


<nCont@at  { 


Object-type 

Object-elass-identifier 

Generator-for-subordinates 

Applieation-coEsaents 


User-readeible-coinnients 
User-visible-name 


7.3.3.15      COME©B^®2St  { 


GENERIC : 
REQ 
REQ 

PERM 

PERM 
PERM 
PERM 
PERM 
REQ 


PERM 
PERM 


Object-type 

Object-class-identifier 
Content -portion 

Resource 
Layout-style 

Presentation-style 

Content-architecture-class 

Application-comments 


User»readabl®-coKBnents 
User-visible-name 


{ STYLE_ID_OF ( p-sty le 1 ) } , 
{$FC|$PC|$FPe}} 


{ 'basic-logical-object' } , 
{REQ  #constraint-name  {"12"}, 
PERM  #external-data  {AHY_VALUE}}, 
{STYLE__ID_OF  (L-Style6 ) } 


{ 'basic-logical-object ' ) , 
{OBJECT_CLASS_ID_OF(FootnoteText) } , 
{CONTENT_ID_OF( 

Character-content-portion)+) ) , 
{REQ  #conatraint-name  {"12"}, 
PERM  #external-data  {ANY_VALUE}}, 
{STYLE_ID_OF (L-Style6 ) } 


{  STyLE__ID_OF  ( P-Sty le  1 )  }  , 

{$FC|$PC|$FPC}} 


{ 'composite-logical-object' } , 
{ANy_¥ALUE}, 
{$CommonContentGFS} , 
{REQ  #constraint-name  {"19"}, 
PERM  #external-data  {ANY_VALUE}}, 
{ANy_STRING} , 
{ANY_STRING}} 


{ 'basic-logical-object ' } , 
{ANY_VALUE}, 
{CONTENT_ID_OF(  ^ 

Character  content-portion)+} , 
{ANY__VM«UE},  ^ 
{STYLE^ID^OF (L-Style3 ) } , 
{STYLE_ID_OF ( P-Style4 ) } , 
{$FC|$PC|$FPC}, 
{REQ  #constraint-name  {"20"}, 
PERM  #external-data  {ANY_VALUE}}, 

{ANY_STRING} , 
{ANY_STRING}} 


I 


—  either  the  attribute  "content  portions"  or  ''resource"  shall  be  specified 
in  the  aibove  constituent  — 


98 


FOD26  Part  1  -  Document  ApplicatiosK  Profile 


July  1992 


7.3.3.16    PageNumber  { 


GENERIC ; 

REQ  Object -type 

REQ  Object-class-identifier 

REQ  Content -generator 

PERM  Layout-atyle 

PERM  Presentation-style 

PERM  Content-architecture-class 

REQ  Application-comments 

PERM  User-readcible-comments 

PERM  User-visible-name 


{ 'basic-logical-object ' } , 
{ANY_VALUE}, 
{$P€NUMBERS}, 
{STYLE_ID_OF (L-Style3 ) } , 
{STyLE_ID_OF (P-Style4 ) } , 
{$FC|$PC|$FPC}, 
{REQ  #constraint-name  {"40*'}, 
PERM  #external-data  {ANY_VALUE}}, 
{ANY_STRING} , 
{ANY  STRING}} 


7.3.3.17    ComiiionGeoinetric  { 


GENERIC : 

REQ  Object -type 

REQ  Object-class-identifier 

PERM  Content -portions 

PERM  Resource 

PERM  Layout-style 

PERM  Presentation-style 

REQ  Content-architecture-class 

REQ  Application-comments 


PERM  User-readed3le-comments 
PERM  User-visible-name 


{  'basic-logical-object ' } , 
{ANY_VALUE}, 

{  CONTENT_ID__OF  ( 

Geometric-graphica-content -portion) } , 
{ANY_VM.UE}, 

{STYLE_ID_OF (L-Style8 ) } , 
{STYLE__ID_0F(P-Style2 )  }  , 
{$FPG}, 

{REQ  #constraint-name  {"22"}, 
PERM  #external-data  {ANY_VALUE}} , 

{ANY__STRING}  , 
{ANY~STRING} } 


—  either  the  attribute  "content  portions' 
in  the  above  constituent  — 


or  "resource"  shall  be  specified 


7.3.3.18    CommonRaster  { 


GENERIC 

REQ  Object-type 

REQ  object-class-identifier 

PERM  Content -portions 

PERM  Resource 

PERM  Layout-Style 

PERM  Presentation-style 

REQ  Content-£irchitecture -class 

REQ  Application-comments 

PERM  User-readedale-comments 

PERM  User-visible-name 


{ 'basic-logical-object ' } , 

{ANY_VALUE}, 

{C0NTENT_ID__0F( 

Raster-graphics-content -portion) } , 
{ANY_VALUE}, 

{STYLE_ID_0F(L-Style8) } , 

{STYLE_ID_OF(P-Style3) } , 
{$FPR}, 

{REQ  #con3traint-name  {"21"}, 
PERM  #external-data  {ANY_VALUE} } , 
{ANY_STRING}  , 
{ANY_STRING} } 


—  either  the  attribute  "content  portions"  or  "resource"  shall  be  specified 
in  the  above  constituent  — 
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7.4  Layout  constituent  constraints 
7.4.1    Macro  definitions 


DEFINE ( DOCLayROOtGFS , 
<con8truction-expr>  : 


<construction-ter]n> 


<construction-type> 


<con8truction-factor> 


DEFINE ( PageSetGFS , 
<con8truction-expr> 


<PageSet-l> 


<con3truction-tenn> 
I <con8truction-type>; 

<construction-factor> 
OPT  <con8tiruction-factor> 
REP  <con8tructiGn-factor> 
OPT  REP  <constx:uction-f actor>; 

SEQ( {<conatruction-tenn>) . . . ) 
I CHO( {<construction-term>} . . . ) ; 

OB JECT_CLASS_ID_OF ( Pageset ) 
j <construction-type>; 


) 


<PageSet-l> 
<PageSet-2> 
<PageSet-3> 

<SEQ  ( <PageSet-lxPageSet  ~2> ) 
<SEQ(<PageSet-lxPageSet-3>) ; 

OB  JECT_CLASS_ID_OF  ( Page ) 
I  OPT  ( OB  JECT_CLASS_ID__OF  ( Page )  )  ; 


<PageSet-2>  : :=  REP(OBJECT_CLASS_ID_OF(Page) ) 

I  OPT  REP ( OB JECT_CLASS_ID_OF ( Page ) ) ; 

<PageSet-3>  opt  REP(SEQ(OBJECT_CLASS__ID__OF(RectoPage) 

OPT ( OB JECT_CLASS_ID_OF ( Ver soPage ) ) ) ) 
I  OPT  REP(SEQ(OBJECT_CLASS_ID_0F(VersoPage) 

OPT(OBJECT_CLASS_ID_OF(RectoPage) ) ) ) 
I  REP  ( SEQ  ( OB JECT__CLASS_ID_OF  ( RectoPage ) 

oPT(OBJECT_CLASS_iD_OF(VersoPage) ) ) ) 
I  REP ( SEQ ( OB JECT_CLASS_1D_0F ( VersoPage ) 

OPT ( OBJECT_CLASS_ID_OF ( RectoPage ) ) ) ) ; 


DEFINE (PageGFS, 
<construction-expr> 


<headerarea> 


<body£u:ea> 


SEQ(  [<headerarea>]<bodyarea>[<footersirea>] ) 
|<bodyarea>; 

OB  JECT_CIiASS_ID__OF  ( Bas  icHeader ) 

I  OBJECT_CLASS_lD_OF  ( Compos iteHeader ) ; 

OB JECT_CLASS_ID_OF ( BasicBody ) 

I OBJECT_CLASS_ID_OF ( VariableCompoaiteBody ) ; 
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<£coterarea> 


OBJECT_CLASS_ID__OF(BasicFooter) 
I  OB JECT_CLASS_ID_OF ( CompositeFooter ) ; 
") 


DEFINE (VariableComposi teBodyGFS , 
<con8truction-expr>  <conatruction-tenn> 

<construction-type> 


<construction-tenn> 


<construction-type> 
<con8truction-£actor> 


<con8truction-£ootnote> 


SEQ(<conatruction-terni>,  <construction-footnote>) 
SEQ(<construction-type>,  <con9truction-£ootnote>) ; 


t:s  <construction-£actor> 

OPT  <construction-factor> 
REP  <construction-£actor> 
OPT  REP  <construction-f actor>; 


SEQ(  {<construction-tenii>} . . . ) 
I CHO( {<construction-tenn>} . . . ) 7 

OBJECT_CLASS_lD_OF  ( BasicFloat ). 
OB  JECT__CLASS__lD_OF  ( snakingColunuis ) 
OB  JECT_CLASS__lD__OF  ( synchronizedColumns ) 
<construction-type>; 

:  =  OB  JECT__CLASS_ID_OF  ( FootnoteArea ) 

I  OPT  OBJECT_CLASS_ID_OF ( FootnoteArea ) ; 


) 


DEFINE  (SnakingColumnsGFS,  ** 

<con8truction-expr>       ::=    SEQ(  {OBJECT_CLASS_lD__OF(ColuinnVariable) } . . . ) 

I  REP  OB JECT_CLASS_lD_OF ( ColumnVariable ) ; 
") 

DEFINE ( SynchronizedColumnsGFS ,  " 

<con8truction>expr >        : :  =    SEQ  ( { OB JECT__cliASS_ID_OF  ( columnFixed )}...)# 
DEFINE (BeaderFooterGFS,  " 

<con8truction-expr>  <£ixed-coinmon-content-fraines> 

I  <variable-coimnon-content-£rames>; 

<£ixed-coinmon-content-£raines> 

: :  m  SEQ  ( { OB JECT_CLASS_lD__OF  ( Sour cedcontentFixed ) 

I  OBJECT__CLASS_ID_OF(ArrangedContentFixed) },,,); 

<variable-coininon-content-£raine8> 

: : «  SEQ ( {OB JECT_CLASS_lD_OF  ( Sourcedcontentvariable ) 

|oBJECT_CLASS_lD_OF(ArrangedContentvariable) > . . . ) ? 


DEFINE ( PAGENUMBER, 


) 


REQ  tbinding-identif ier { " "PGnum" " ) , 

REQ  #binding-value  {<niun-expr> : :  =INC  ( B_REF  ( PREC  ( 

CURR-OBJ) ) ( " "PGnum" " ) ) ; } 

-) 
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DEFINE (INITIALISEPGNUM,  " 

{REQ  #binding-identifier{""PGnuin""}, 
REQ  #binding-value{>«-l}} 
") 

DEFINE ( PDA-FPDA,  " { 'processable ' I ' f ormatted-processable ' } " ) 


7.4.2    Factor  constraints 


7.4.2.1     FACTOR  ANY-LAYOUT  { 


GENERIC : 
REQ 
REQ 
REQ 

SPECIFICS 
PERM 
REQ 
CASE 
$FDA: 


Object -type 

Object-class -identifier 
Application-cononents 

Object -type 
Object-identifier 
$DAC  OF  { 
PERM  Object-class 


$FPDA:  REQ  Object-class 
}/ 

REQ  Subordinates 
PERM  Application-comments 
SPECIFIC_AND_GENERIC  s 

PERM  User-readsddle-comments 
PERM  User-visible-name 


{VIRTUAL} , 

{ANy_VALUE}, 

{VIRTUAL} 

{VIRTUAL}, 
{ANY_VALUE}, 

{VIRTUAL} 
{VIRTUAL} 

{VIRTUAL} , 
{VIRTUAL} 

{ANy_STRING} , 
{ANY_STRING}} 


7.4.2.2     FACTOR  ANY -PAGE:  ANY-LAYOUT  { 
GENERIC: 

REQ     Object-type  {'P*g©'}# 
CASE     $DAC  OF  { 
$PDA-FPDA: 

REQ     Generator-for-subordinates  {$PageGFS}, 
PERM    Bindings  { $PAGENUMBER} 

}/ 


SPECIFIC : 

PERM  Object-type 
REQ  Subordinates 


{'page'}, 

{ STO_ID_0F ( BasicHeader ) , 
SUB_ID__OF(CompositeHeader) , 
SUB_ID_OF(BasicBody) , 
SUB_ID__OF  ( VariableCompositeBody ) , 
SUB_ID__OF(BasicFooter) , 
SUB_ID__OF(  Compos  iteFooter) } 
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SPECIFIC_AND_GENERIC : 
PERM  Dimensions 


PERM    Page -position 


{{REQ  fhorizontal-dimension 

{REQ  # fixed-dimension  {<=14030}}, 
REQ  fvertical-dimension 
{REQ  #£ixed-dimenaion  {<-19840)}>} 

—  up  to  ISO  A3  portrait  — 
I {REQ  fhorizontal-dimension 

{REQ  # fixed-dimension  {<»19840}}, 
REQ  fvertical-dimension 

{REQ  #f ixed-dimension  {<>14030}}}, 

—  up  to  ISO  A3  landscape  — 
I {REQ  fhorizontal-dimension 

{REQ  f fixed-dimension  {<=13200}}, 
REQ  fvertical-dimension 

{REQ  f fixed-dimension  {<=20400)}}> 

—  up  to  ANSI-B  portrait  — 
I {REQ  fhorizontal-dimension 

{REQ  f fixed-dimension  {<=20400}}, 
REQ  fvertical-dimension 

{REQ  f fixed-dimension  {<=13200}}} 

—  up  to  ANSI-B  landscape  — }, 
{ANy_VALUE}} 


7.4.2.3     FACTOR  ANY -FRAME -FIXED:  ANY-: 

GENERIC : 

REQ  Object-type 
SPECIFIC: 

PERM  Object-type 
SPECIFIC_AND__GENERIC : 

PERM  Position 


PERM  Dimensions 


PERM  Border 


{ 


{ ' frame ' } 
{ ' frame ' } 

{REQ  f fixed-position 

{REQ  f horizontal-position  {ANY_VALUE}, 
REQ  fvertical-position  {ANY__VALUE} } } , 
{REQ  fhorizontal-dimension 

{REQ  f fixed-dimension  {ANY_VALUE}}, 
REQ  fvertical-dimension 

{REQ  f fixed-dimension  {ANY__VALUE} } } , 
{ANY_VALUE}} 


7.4.2.4     FACTOR  ANY -FRAME -VARIABLE:  ANY -LAYOUT  { 
GENERIC : 

REQ       Object-type  {'fraone'} 
SPECIFIC: 

PERM     Object-type  {'frame'), 
CASE       $DAC  OF  { 

$FPDA:  REQ      Position         {REQ  f fixed-position 

{REQ  f horizontal-position  {ANY_VALUE}, 
REQ  fvertical-position  {ANY_VALUE} } } , 
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REQ     Dimensions       {REQ  ihorizontal-dimension 

{REQ  ffixed-dimension  {ANY_VAIiUE}}, 
REQ  tvertical-dimension 
{REQ  tfixed-dimension  {ANT_VALUE}}} 

} 

specific_and_generic : 
case"   $dac  op  { 

$FDA:      PERM     Position      {REQ  # fixed-position 

{REQ  fhorizontal-position  {ANY_VALUE}, 
REQ  tvertical-position  {ANY_yM.UE}}>, 
PERM     Dimensions  {REQ  fhorizontal-dimension 

{REQ  tfixed-dimension  {ANY_yALUE}>, 
REQ  tvertical-dimension 

{REQ  tfixed-dimension  {ANY_VALUE>}} 

}. 

PERM     Border  {ANy_VALUE} 


7.4.2.5     FACTOR  BLOCK  { 
SPECIFIC : 

REQ     Object-type  {'block'}, 
REQ      Object-identifier  {ANY  VALUE), 

PERM    content-architecture-class  {$FcJ$FPC | $FPr| $FPG) , 
PERM    Presentation-attributes  { 
PERM  tcharacter-attributes  { 


PERM 

ialignment 

{ANY_VALUE}, 

PERM 

#character-fonts 

{ANY_VALUE}, 

PERM 

fcharacter-spacing 

{ANY_VALUE} , 

PERM 

#character-orientation 

'0-degrees ' 

'90-degrees'}, 

PERM 

#cheu:acter-path 

'O-degrees ' 

'90-degrees'} 

'ISO-degrees'} 

'27 O-degrees'}, 

PERM 

tcode-extension-announcers  \ 

:$CDEXTAN}, 

PERM 

ifirst-line-offset 

{ANY__VALUE), 

PERM 

#graphic -character-sets 

{ $PERMIT-GRCHAR} , 

PERM 

#  graphic -c har ac t er - s ubr epertoir e 

{ANY_VALUE}, 

PERM 

#gr aphic -rendition 

{$GRAPHICR£NDITIONS} , 

PERM 

fitemisation 

{ANY_VALUE) , 

PERM 

#kerning-off set 

{ANY~VALUE}, 

PERM 

tline-layout-table 

{ANY_VALUE) , 

PERM 

tline-progression 

{'90  degrees' 1 '27 O-degrees'}, 

PERM 

#line-spacing 

{ANY_VALUE), 

PERM 

#initial-of f set 

{ANY_VALUE}}}, 
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PERM  User-readable-comments 
PERM  Uaer-visible-naoie 
^ERM  Position 


PERM  Dimensions 


{ANY_STRING}, 
{ANY_STRING} , 
{REQ  #fixed-position 

{REQ  thorizontal-position  {ANY_VALUE), 
REQ  #vertical-poaition  {ANY^VALUE} } ) , 
{REQ  ihorizontal-dimension 

{REQ  # fixed-dimension  {ANY_VALUE}), 
REQ  #vertical-dimension 
{REQ  #fixed-dimension  {ANY__VALUE}>}> 


7.4.3    Constituent  constraints 


7.4.3.1    DocumentLayoutRoot:  ANY-LAYOUT  { 


GENERIC : 

REQ  Object-type 
CASE       $DAC  OF  { 

$PDA-FPDA: 
REQ       Generator-f or-subordinates 
PERM  Bindings 
}, 

REQ  Application-comments 

SPECIFIC : 

PERM  Object-type 
CASE     $DAC  OF  { 

$FDA:      PERM  Object-class 

$FPDA:    REQ  Object-class 

REQ  Siibordinates 

PERM  Application-comments 


{  'document-layout -root ' } , 


{$DocLayRootGFS} ,  . 
{ $INITIALISEPGNUM) 

{REQ  #constraint-name  {"0"}, 
PERM  texternal-data  {ANY_VALUE}} 

{ 'document-layout -root ' > , 

{ OB JECT_CLASS_lD_OF 

(DocumentLayoutRoot) > 
{  OB  JECT_CLASS_1D__0F 

(DocumentLayoutRoot) } 

{ SUB_ID_OF ( PageSet ) + } , 
{REQ  Icons traint-name  {"0"}, 
PERM  #external-data  {ANY_VALUE)}) 


7.4.3.2    PageSet:  ANY-LAYOUT  { 
GENERIC: 

REQ       Object-type  {'page-set'}, 
CASE       $DAC  of  { 
$PDA-FPDA: 

REQ       Generator-f or-subordinates    {$PageSetGFS} , 
PERM       Bindings  {$INITIALISEPGNUM} 
>. 

REQ       Application-comments  {REQ  tconstraint-name  {"1"}, 

PERM  texternal-data  {ANY_VALUE}} 
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{ 'page-set' } 


SPECIFIC: 

PERM  Object-type 
CASE     $DAC  OF  { 

$FDA;      PERM    Object-clasa    {03JECT_CLASS_ID_0F(PageSet) > , 
$FPDA:    REQ      Object-class     {OBJECT_CLASS_lD_OF(PageSet) } 
}/ 

REQ       Subordinates  {SUB_ID_OF(Page)+, 

SUB_ID~OF ( RectoPage ) + , 
SUB_ID_or ( Ver soPage ) + ) , 

PERM     Applic at ion-comments  {REQ  #constraint-name  {"l"}, 

PERM  #external-data  {ANY_VALUE}}} 


7.4.3.3    Page:  ANY-PAGE  { 

Application-comments 


GENERIC : 
REQ 


SPECIFIC: 
CASE 


{REQ  #constraint-name  {"2"), 
PERM  #external-data  {ANY_VALUE)) 


$DAC  OF  { 

$FDA:     PERM    Object-class       {OBJECT_CLASS_ID_OF(Page) } 
$FPDA:  REQ      Object-class      {OBJECT_CLASS_lD_OF(Page) } 
}. 

PERM      Application-comments  {REQ  #constraint-name  {"2"), 

PERM  #external-data  {ANY__VALUE}} 

SPECIFIC_AND_GENERIC : 

PERM      Medium-type  {PERM  #nominal-page-size 

{ $NominalPageSizes } , 
PERM  #side-of -sheet  {ANY_VALUE}}} 


7.4.3.4    RectoPage:  ANY-PAGE  { 


GENERIC : 
REQ 

REQ 


SPECIFIC! 
CASE 


PERM 
PERM 


Application-comments 
Medium-type 


{REQ  #constraint-name  {"3"}, 
PERM  #external-data  {ANY_VAHJE} } , 
{PERM  #nominal-page-size 

{ $NominalPageSize8 } , 
REQ  #side-of-sheet 

{'recto' I 'unspecified'}) 


$DAC  OF  { 

$FDA:  PERM  Object-class  { OB JECT_CLASS_ID_OF( RectoPage ) } 
$FPDA:  REQ      Object-class      { OB JECT_CLASS_ID_OF( RectoPage ) } 


Application-comments 
Medium-type 


{REQ  #constraint-name  {"3"}, 
PERM  #external-data  {ANY_VALUE}}, 
{PERM  #nominal-page-size 

{ $NominalPageSizes } , 
PERM  #side-of-sheet 

{'recto' I 'unspecified')} 
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7.4.3.5    VeraoPage:  ANY -PAGE  { 


GENERIC  t 
REQ 

REQ 


SPECIFIC: 
CASE 


PERM 
PERM 


Application-comnents 
Medium-type 


$DAC  OF  { 

$FOAt    PERM  Object-class 
$FPDA:  REQ  Object-class 
>/ 

Application-comments 
Medium-type 


{REQ  #con8traint-name  {"4"}, 
PERM  «external-data  {ANY_VALUE}}, 
{PERM    fnominal -page-size 

{ $NominalPagesizes } , 
REQ  #8ide-o£-sheet 

{ 'verso ' j 'unspecified ' } } 


{OBJECT__CLASS_ID_OF  (VersoPage ) } 
{  OB  JECT_CLASS__ID_OF  ( Ver  soPage ) } 

{REQ  <constraint-name  {"4"}, 
PERM  #external-data  {ANY_VALUE}} , 
{PERM  #nominal-page-size 

{$NominalPageSizes} , 
PERM  #side-of -sheet 

{ 'verso ' j 'unspecified ' } ) ) 


7.4.3.6    BaaicBody:  ANY-FRAME -FIXED  { 


GENERIC : 
PERM 


SPECIFIC  t 
CASE 


REQ 
PERM 


Layout-path 


REQ  Application-comments 


$DAC  OF  { 

$FDA:  PERM 
$FPDA:  REQ 
>/ 

Subordinates 
Application-comments 


Object-class 
Object-class 


{ '270-degrees'  —  page  layout  A  — 
0-degrees'      —  page  layout  B  — 
'180-degrees'  —  page  layouts 

C  and  D  — }, 
{REQ  #constraint-name  {**28'*}, 
PERM  #external-data  {ANY_VALUE}} 


{  OB JECT_CLASS_ID__OF  ( Bas  icBody )  } 
{OBJECT_CLASS_ID_OF(BasicBody) > 

{  SUB_ID__0F(  specif  icBlock)+} , 
{REQ  #constraint-name  {"28"}, 
PERM  #external-data  {ANY_VALUE}}} 
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7.4.3.7    VariableConpositeBody:  ANY-FRAME -FIXED  { 


GENERIC: 
CASE 


SPECIFIC: 
CASE 


REQ 


$DAC  OF  { 
$PDA-FPDA: 

REQ  Generator-for-8ubordinatea 

{$VariableCoo^o8iteBodyGFS} , 


PERM  Layout-path 


I^Q  Application-comments 


$DAC  OF  { 

$FDA:    PERM  Object-class 

$FPOA:  REQ  object-class 
>, 

Svibordinates 


PERM  Application-comments 


{'270-degree8'  —  page  layout  A  — 

I'O-degrees'  —  page  layout  B  — 
'  180-degreea '  —  page  layouts 

C  and  D  — } 

{REQ  #constraint-name  {"7"}, 
PERM  #extemal-data  {ANT_VALUE}} 


{ OB JECT_CLASS_ID_OF 

(VariableCompositeBody ) } , 
{OBJECT__CLASS_ID__OF 

(VariableCompositeBody) } 

{ SUB_lD_OF ( Bas  icFloat ) + , 
SUB_I0_0F  ( snakingcolumns )  -f , 
SUB_ID_OF  ( SynchronizedColumns )  -f , 
SUB__ID_OF  ( FootnoteArea ) } , 

{REQ  fconstraint-name  {"7"}, 
PERM  #external-data  {ANY_VALUE>}} 


7.4.3.8    BaaicFloat:  ANY-FRAME-VARIABLE  { 


GENERIC: 
CASE 


$DAC  OF  { 
$PDA-FPDA: 
REQ  Position 


{REQ  #variable-position  { 

PERM  toffset  {ANY_VALUE>, 

PERM  # separation  7any_VALUE>, 

PERM  falignment  {ANY_VALUE}, 

PERM  «f ill-order  {'normal-order'}}}. 


PERM    Permitted-categories  {ANY_STRING} 

CASE  SUPERIOR  (VariableCompositeBody (Layout-path) )  OF  { 
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{ '270-degrees' } ;  —  page  layout  A  — 

REQ    Dimensions         {REQ  thorizontal-dimension 

{REQ  #f ixed-dimension  {Airy_VALUE} , 
I REQ  tmaximum-size  { ' applies '}} , 
REQ  #vertical-diinension 

{REQ  #rule-b  {ANY_VALUE}}}, 
PERM  Layout -path        {  '  270-degrees ' } 
{ ' 0-degrees ' } :  —  page  layout  B  — 

REQ    Dimensions         {REQ  fhorizontal-dimension 

{REQ  #rule-b  {ANY_VALUE}}, 
REQ  fvertical-dimension 

{REQ  # fixed-dimension  {ANY_VALUE} 
I REQ  #maximum-size  { ' applies ' } ) } , 
REQ    Layout -path  {'0-degrees'} 

{ ' 180-degrees' } :  —  page  layouts  C  and  D  — 

REQ    Dimensions  {REQ  Ihorizontal-dimension 

{REQ  #rule-b  {ANY_VALUE}}, 
REQ  #vertical-dimension 

{REQ  # fixed-dimension  {ANY_VALUE} 
I REQ  #maximum-size  {'applies'}}), 
REQ    Layout -path  {'180-degrees'} 

) 

}' 

REQ       Application-comments  {REQ  #constraint-name  {"12"}, 

PERM  #external-data  {ANY_VALUE}} 

SPECIFIC: 

CASE       $DAC  OF  { 

$FDA:     PERM    Object-class       {OBJECT_CLASS_ID_OF(BasicFloat) } , 
$FPDA:  REQ      Object-class      {0BJECT_CLASS_ID_OF(BasicFloat) } 

REQ       Subordinates  {SUB_ID_0F ( Specif icBlock)+} , 

PERM     Application-comments  {REQ  #constraint-name  {"12"}, 

PERM  #external-data  {ANY_VALUE} } } 


7.4.3.9    SynchronizedColumna :  ANY -FRAME -VARIABLE  { 

GENERIC : 

CASE       $DAC  OF  { 

$PDA-FPDA: 

REQ  Generator-for-subordinates 

{$SynchronizedColumnsGFS} , 

REQ       Position  {REQ  #variable-position  { 

PERM  toffset  {ANY_VALUE}, 
PERM  tseparation  {ANY_VALUE}, 
PERM  talignment  {ANY_VALUE}, 
PERM  #fill-order  { 'normal -order '} } 

CASE  SUPERIOR  (V2a:iableCompositeBody (Layout -path) )  OF  { 
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{ '270-degreeB') :  —  page  layout  A  — 

REQ    Dimensions      {REQ  fhorizontal-dimension 

{REQ  ffixed-dimension  {ANY^VALUE) 
I  REQ  tmeucimum-size  {'applies'}}, 
REQ  #vertical-dimension 

{REQ  #rule-b  {ANY_VALUE}}}, 
PERM  Layout-path    { '270>degree8'} 

{ ' 0-degrees ' } :  —  page  layout  B  — 

REQ    Dimensions      {REQ  fhorizontal-dimension 

{REQ  #rule-b  {ANY_VALUE}}, 
REQ  ivertical-dimension 

{REQ  # fixed-dimension  {ANY_VALUE} 
I REQ  fmaximum-size  {'applies'}}}, 
REQ    Layout -path    { ' 0-degrees ' } 


REQ 

SPECIFIC: 
CASE 


{ '180-degrees ' } :  —  page  layouts  C  and  D  — 

REQ    Dimensions      {REQ  fhorizontal-dimension 

{REQ  #rule-b  {ANY_VALUE}}, 
REQ  fvertical-diniension 

{REQ  #fixed-dimension  {ANY__VALUE} 
I REQ  fmaximum-size  {'applies'}}}, 
REQ    Layout -path    { ' 180-degrees ' } 

} 

Application-comments  {REQ  f constraint-name  {"11"}, 

PERM  f external -data  {ANY_VALUE}} 


REQ 
PERM 


$DAC  OF  { 

$FDA:    PERM  Object-class 

$FPDA:  REQ  Object-class 


Siibordinates 
Application-comments 


{ OB JECT_CLASS_ID_OF 

( synchronizedColumns ) } 
{  OB  JECT_CLASS__ID_OF 

( SynchronizedColumns ) } 

{  SUB__ID_OF  ( ColumnFixed )  +  } , 
{REQ  f constraint-name  {"11"}, 
PERM  f external -data  {ANY_VALUE}}} 


7.4.3.10    SnaJcingColumns :  ANY -FRAME -VARIABLE  { 


GENERIC : 
CASE 


$DAC  OF  { 
$PDA-FPDA: 

REQ    Generator-for-subordinates    {$SnakingColumnsGFS} , 
REQ    Position  {REQ  f variable -position  { 

PERM  foffset  {ANY_VALUE}, 
PERM  f separation  {ANY_VALUE}, 
PERM  f alignment  {ANY_VALUE}, 
PERM  f fill-order  {'normal-order'}}, 
PERM  Balance  {ANY_VALUE} 

CASE  SUPERIOR  (VariableCompositeBody (Layout -path) )  OF  { 
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{ '270-degrees ' ) :  —  page  layout  A  — 

REQ    Dimensions      {REQ  thorizontal-dimension 

{REQ  ifixed-dimension  {ANY_VALUE} 
I REQ  imaximum-size  { ' applies ' } } , 
REQ  fvertical-dimension 
{REQ  #rule-b  {ANY_VALUE))}, 
REQ    Layout -path    { ' 0-degrees ' | ' 180-degrees ' } 

{ ' 0-degrees ' } :  ~  page  layout  B  — 

REQ    Dimensions      {REQ  thorizontal-dimension 

{REQ  #rule-b  {ANY_VALUE}}, 
REQ  fvertical-dimension 

{REQ  # fixed-dimension  {ANY_VALUE} 
I  REQ  imaximum-size  { ' applies ' } } } , 
PERM  Layout -path    { '90-degree8 ' | '270-degrees ' } 

{ '  180-degrees ' } :  —  page  layouts  C  and  D  — 

REQ    Dimensions      {REQ  thorizontal-dimension 

{REQ  trule-b  {ANY_VALUE}}, 
REQ  tvertical-dimension 

{REQ  tfixed-dimension  {ANY_VALUE} 
I REQ  tmaximum-size  { ' applies ' } } } / 
PERM  Layout -path    { ' 27 0-degrees ' } 


> 

REQ  Application-comments 


SPECIFIC : 
CASE 


REQ 
PERM 


$DAC  OF 
$FDA: 


{ 


PERM  Object-class 
$FPDA:  REQ  Object-class 

Subordinates 
Application-comments 


{REQ  tconstraint-name  {"10"), 
PERM  texternal-data  {ANY__VALUE} } 


{OBJECT_CLASS_ID_OF 

( snaJcingColumns ) } 

{  OB  JECT__CLASS_ID__OF 

( snakingcolumns ) } 

{SUB_ID_0F  (ColumnVariable ) +) , 
{REQ  tconstraint-name  {"10"}, 
PERM  texternal-data  { ANY__VALUE  }  }  } 


7.4.3.11    ColumnVariable:  ANY -FRAME -VARIABLE  { 

GENERIC : 

CASE       $DAC  OF  { 

$PDA-FPDA: 

PERM    Permitted-categories    {ANY_STRING} , 

REQ      Position  {REQ  tvariaible-position  { 

PERM  toff set  {ANY_VALUE}, 
PERM  t separation  {ANY_VALUE), 
PERM  talignment  {ANY_VALUE}, 
PERM  tf ill-order  { 'normal -order '} } 
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REQ 

SPECIFIC: 
CASE 


REQ 
PERM 


CASE  SUPERIOR  ( VaLriablecompositeBody  (Layout-path) )  OF  { 

{ '270-degrGe8'} :     —  page  layout  A  — 

REQ    Dimensions       {REQ  fhorizontal-dimension 

{REQ  # fixed-dimension  {ANY^VALUE}}, 
REQ  fvertical-dimension 
{REQ  #rule-b  {ANY_VALUE} 
I REQ  #maximum-size  { ' applies ' } > } , 
PERM  Layout -path      { '270-degrees'} 

{ '0-degrees ' } :  —  page  layout  B  — 

REQ    Dimensions       {REQ  fhorizontal-dimension 

{REQ  #rule-b  {ANY_VALUE} 
I REQ  #maximum-size  { ' applies ' } } , 
REQ  fvertical-dimension 

{REQ  # fixed-dimension  {ANY_VALUE}}}, 
{ '0-degrees'} 


REQ  Layout-path 

{ ' 180-degrees ' ) :  —  page 
REQ  Dimensions 


REQ  Layout-path 
Application-comments 


layouts  c  and  D  — 

{REQ  fhorizontal-dimension 
{REQ  frule-b  {ANY_VALUE} 
I REQ  f maximum-size  {'applies'}}, 
REQ  fvertical-dimension 

{Pj:q  f fixed-dimension  {ANY_VALUE}}} 
{ '180-degrees'} 

{REQ  f constraint-name  {"9"}, 
PERM  f external-data  {ANY_VALXn:}}, 


$DAC  OF  { 

$FDA:  PERM  Object-class 
$FPDA:  REQ  Object-class 

Subordinates 
Application-comments 


{ OB  JECT_CLASS_iD__OF  ( Columnvar  iable ) } 
{OBJECT_CLASS_lD_OF  ( columnVariaJsle ) } 

{SUB_ID_OF ( Specif icBlock ) + ) } , 
{REQ  f constraint-name  {"9"}, 
PERM  f external-data  {ANY__VALUE}}} 


7.4.3.12     ColumnPixed:  ANY -FRAME -VARIABLE  { 


GENERIC : 
CASE 


$DAC  OF  { 
$PDA-FPDA: 


REQ  Permitted-categories  {ANY_STRING} , 
REQ  Position 


{REQ  f fixed-position 

{REQ  f horizontal-position  {ANY_VALUE}, 
REQ  fvertical -position  {ANY_VALUE}}} 


CASE  SUPERIOR  (V2u:iableCompositeBody (Layout -path) )  OF  { 
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{'270-degrea8')t  —  page  layout  a  — 


REQ  Dimensions 


PERM  Layout-path 


{REQ  fhorizontal-dimension 

{REQ  ifixed-dimension  {ANY__VALUE}, 
I REQ  tmaxiBum-size  {'applies}}, 
REQ  ivertical -dimension 
{REQ  #rule-b  {ANY_VALUE} 
I REQ  tmaximuffl-size  { ' applies ' } } } , 
{'270-degrees'} 


{ ' O-degrees ' } :  —  page  layout  B  — 

REQ    Dimensions      {REQ  thorizontal-dimension 

{REQ  #rule-b  {ANY_VALUE} 
I REQ  tmaximuffi-size  {'applies'}}, 
REQ  fvertical-dimension 
{REQ  tfixed-dimension  {ANY_VALUE} 
I REQ  #maximum-size  {'applies'}}}, 
REQ    Layout -path    { '0-degrees'} 


{'180-degrees'} :  —  page 
REQ  Dimensions 


layouts  C  and  D  — 
{REQ  ihorizontal-^imension 

{REQ  #maximum-size  { ' applies ' } } , 
REQ  #vertical -dimension 
{REQ  tfixed-dimension  {ANY_VALUE} 
I  REQ  fmaiximum-size  {'applies'}}, 
REQ    Layout -path  {'180-degrees'} 


} 


REQ  Application-comments 


{REQ  #constraint-name  {8"}, 
PERM  «external-data  {ANY_VALUE}} 


SPECIFIC: 
CASE 


REQ 
PERM 


$DAC  OF  { 

$FDA:  PERM  Object-class 
$FPDA:  REQ  object-class 

Subordinates 
implication-comments 


{OBJECT_CLASS__ID_OF 

(ColumnFixed) } 

{OBJECT_CLASS_ID_OF 

(ColumnFixed) } 

{SUB_lD__OF(Specif  icBlock)+} , 
{REQ  tconstraint-name  {"8"}, 
PERM  «external-data  {ANY_VALUE}}} 


7.4.3.13    FootnoteArea:  ANY-FRAME -VARIABLE  { 

GENERICS 

CASE       $OAC  OF  { 
$PDA-FPDA: 

REQ     Position  {REQ  tvariable -position  { 

PERM  foffset  {ANY_VALUE}, 

PERM  fseparation  {ANY_VALUE}, 

PERM  #alignment  {ANY_VALUE}, 

REQ    #f ill-order  {'reverse-order'}}. 
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REQ      Permitted-categories  {"Footnote"} 

CASE  SUPERIOR  (VariableCos^ositeBody (Layout-path) )  OF  { 

{ '270-degree8'} :  —  page  layout  A  — 

REQ    Dimensions      {REQ  fhorizontal -dimension 

{REQ  ifixed-dimension  {ANY^VALUE} 
I REQ  #maximum-size  {'applies'}}, 
REQ  tvertical-dimension 
{REQ  #rule-b  {ANY_VALUE}}}, 
PERM  Layout-path    { '270-degreea'} 

{'0-degrees'}:  —  page  layout  B  — 

REQ    Dimensions      {REQ  thorizontal-dimension 

{REQ  #rule-b  {ANY_VALUE}}, 
REQ  #vertical-dimension 
{REQ  # fixed-dimension  {ANY^VALUE} 
I REQ  #maximuffl-size  {'applies'}}}, 
REQ    Layout -path    {' 0-degrees '} 

{'180-degrees'}:  —  page  layouts  C  and  D  — 

REQ    Dimensions      {REQ  ihorizontal-dimension 

{REQ  #rule-b  {ANY_VALUB}}, 
REQ  tvertical-dimension 
{REQ  tfixed-dimension  {ANY_VALUE} 
I REQ  #maximum-size  {'applies'}}}, 
REQ    Layout-path  {'180-degrees'} 


} 

}. 

REQ  Application-comments 


SPECIFIC! 
CASE 


REQ 
PERM 


$DAC  OF  { 

$FDA:    PERM  Object-class 
$FPDA:  REQ  Object-class 
}/ 

Subordinates 
Application-comments 


{REQ  #constraint-naune  {"15"}, 
PERM  #external-data  {ANT_VALUE}} 


{ OB  JECT__CLASS_lD_OF  ( FootnoteArea ) } 
{OBJECT_ciASS_iD_OF(FootnoteArea) } 

{SUB_lD_OF( Specif icBlock)+} , 
{REQ  #constraint-name  {"15"}, 
PERM  *external-data  {ANY_VALUE}}} 


7.4.3.14 

BasicHeader:  ANY-FRAME 

GENERIC: 

CASE 

$DAC  0F{ 

$PDA-FPDA: 

REQ 

Logical-source 

PERM 

Layout-path 

REQ 

Application-comments 

{OBJECT_CLASS_iD__OF  ( commonContent ) } } , 
{ '27 0-degrees '  —  page  layouts  A,B,C  • 

j '180-degrees'  —  page  layout  D  — }, 
{REQ  fconstraint-name  {"27"}, 

PERM  #external-data  {ANY__VALUE} } , 
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SPECIFIC: 

CASE       $DAC  OF  { 

$FDA:    PERM  Object-class 
$FPOA:  REQ  Object-class 
)/ 

REQ  Subordinates 

PERM  Application-cosnnents 


{OBJECT_CLASS_ID_OF(BasicHeader) } 
{OBJECT_CLASS_ID_OF(BasicHeader) } 

{SUB_ID_OF ( Specif icBlock)+} , 
{REQ  #constraint-name  {"21"), 
PERM  #external-data  {ANy_VALUE)}} 


7.4.3.15    BasicFooter:  ANY-FRAME -FIXED 

GENERIC: 

CASE       $DAC  0F{ 

$PDA-FPDA: 
REQ  Logical-source 
PERM  Layout-path 

REQ  Application-comments 

SPECIFIC : 

CASE       $DAC  OF  { 

$FDA:    PERM  Object-class 
$FPDA:  REQ  Object-class 
}, 

REQ  Subordinates 

PERM  Application-comments 


{OBJECT_CLASS_ID_OF(CommonContent) } } , 
{ '270-degrees '  —  page  layouts  A,B,C  — 

I ' 180-degrees '  —  page  layout  D  — }, 
{REQ  #constraint-name  {"33"}, 

PERM  #external-data  {ANy_VALUE} } , 


{OBJECT_CLASS_ID_OF(BasicFooter) } 
{OBJECT_CLASS_ID_OF( BasicFooter) } 

{SUB_ID_OF(SpecificBlock)+} , 
{REQ  #constraint-name  {"33"}, 
PERM  #external-data  {ANy_VALUE} } } 


7.4.3.16    Caiq>oaiteHeader:  ANY-FRAME-FIXED  { 


GENERIC: 
CASE 

REQ 

PERM 

REQ 

SPECIFIC: 
CASE 


REQ 


$DAC  OF  { 
$PDA-FPDA: 

Generator-for-subordinates 
}/ 

Layout-path 
Application-comments 


$DAC  OF  { 
$FDA:  PERM 
$FPDA:  REQ 

Subordinates 


Object-class 
Object-class 


PERM  Application-comments 


{$BeaderFooterGFS} 

{'270-degrees'  —  page  layouts  A,B,C  — 
I ' 180-degrees '  —  page  layout  D  — }, 

{REQ  #constraint-name  {"5"}, 
PERM  #external-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF ( Compos iteHeader ) } 
{OBJECT_CLASS_ID_OF( Compos iteHeader) } 

{ SUB_ID_OF ( SourcedContentFixed ) + , 
SUB_ID_OF ( Ar r angedContentFixed ) + , 
SUB_ID_OF ( SourcedContentVar iable ) + , 
SUB_ID_OF(ArrangedContentVariable ) +} , 

{REQ  #constraint-name  {"5"}, 
PERM  #external-data  {ANY_VALUE}}} 
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7.4.3.17    Ccn^siteFooter:  ANY-FRAME -FIXED  { 


GENERIC : 
CASE 

REQ 

PERM 

REQ 

SPECIFIC! 
CASE 


REQ 


$DAC  OF  { 
$PDA-FPDA: 

Generator-for-subordinates 
}/ 

Layout -path 
Application-comments 


$DAC  OF  { 
$FDA:  PERM 
$FPDA:  REQ 
}/ 

Subordinates 


Object-class 
Object-class 


PERM  Application-comments 


{ $HeaderFooterGFS } 

{ '270-degrees'  —  page  layouts  A^B^C  — 
I '180-degrees'  —  page  layout  D  --}/ 

{REQ  #constraint-name  {"32"}, 
PERM  #external-data  {ANY_VALUE}>, 


{OBJECT_CLASS_ID_OF ( Compos iteFooter ) } 
{OBJECT_CLASS_lD_OF ( compositeFooter ) } 

{ SUB_ID_OF ( SourcedContentFixed ) + , 
SUB_ID_OF ( Arr angedContentFixed ) + , 
SUB_ID_OF  ( SourcedContentVeuriable ) +, 
SUB_ID_OF  ( ArrangeidContentVariable )  +  } , 

{REQ  #constraint-name  {"32"), 
PERM  #external-data  {ANY_VALUE}}} 


7.4.3.18    SourcedContentVariable:  ANY -FRAME -VARIABLE  { 


GENERIC : 
CASE 


$DAC  OF  { 
$PDA-FPDA: 


REQ 
REQ 


Logical -source 
Position 


{OBJECT_CLASS_lD_OF ( Commoncontent ) ) , 

{REQ  tvariable-position  { 
PERM  toff  set  {ANY__VALUE}, 
PERM  iseparation  {ANY_VALUE}, 
PERM  talignment  {ANY_VALUE>, 
PERM  #f ill-order  {' normal -order ') > 


CASE  SUPERIOR  (CompositeHeader | CompositeFooter 

(Layout -path) )  OF  { 


{ '270-degrees'} : 

REQ  Dimensions 


PERM  Layout-path 
{'180-degrees'}: 

REQ  Dimensions 


{REQ  thorizontal-dimension 

{REQ  # fixed-dimension  {ANY__VALUE} 
I REQ  #maximum-size  { ' applies ' } } , 
REQ  #vertical-dimension 

{REQ  #fixed-dimension  {ANY__VALUE} 
I REQ  #rule-b  {ANY_VALUE}}}7 

{ '270-degrees ' } 

{REQ  thorizontal-dimension 

{REQ  # fixed-dimension  {ANY_VALUE} 
I REQ  #rule-b  {ANY_VALUE}}, 
REQ  #vertical-dimension 

{REQ  ffixed-dimension  {ANY_VALUE} 
[req  #maximum-size  {'applies'}}}. 
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REQ 

SPECIFIC: 
CASE 


REQ 
PERM 


REQ  Layout-path 
) 

} 

Application-comments 


$DAC  OF  { 

$FDA:    PERM  Object-class 
$FPDAt  REQ  Object-class 
}, 

Subordinates 
Application-comments 


{ '180-degrees'} 


{REQ  #constraint-name  {"19"}, 
PERM  #external-data  {ANY_VALUE}} 


{ OB JECT_CLASS_ID_OF 

( SourcedContentVauriable ) } 
{  OB  JECT_CLASS__ID__OF 

( SourcedContentVar iable ) } 

{SUB_ID_OF ( Specif icBlock)+} , 
{REQ  tconstraint-name  {"19"}, 
PERM  #external-data  {ANY_value} } } 


7.4.3.19    ArrangedContentVariable:  ANY -FRAME -VARIABLE  { 

GENERIC: 

CASE       $DAC  OF  { 
$PDA-FPDA: 


REQ 


REQ 


Position 


Gener ator-f or - subordinate  s 

{<construction-expr> : :=SEQ 
(OBJECT_CLASS_ID_OF( Gener icBlock) ...);}» 
{REQ  fvariable-position  { 
PERM  #offset  {ANY_VALUE}, 
PERM  #separation  {ANY_VALUE}, 
PERM  #alignment  {ANY_VALUE}, 
PERM  #f ill-order  {'normal-order'}}, 
{REQ  thorizontal-dimension 

{REQ  # fixed-dimension  {ANY_VALUE}, 
REQ  ivertical-dimension 
{REQ  « fixed-dimension  {ANY_VALUE} } , 


REQ  Dimensions 


REQ  Application-comments 


SPE  CIFIC: 
CASE       $DAC  OF  { 
$FDA: 


PERM  Object-class 


REQ 
PERM 


$FPDA:  REQ  Object-class 

Subordinates 
Application-comments 


{REQ  tconstraint-name  {"17"}, 
PERM  #external-data  {ANY_VALUE}} , 


{OBJECT_CLASS_ID_OF 

(ArrangedContentVariable ) } 
{ OB JECT_CLASS_ID_OF 

(ArrangedContentVariable) } 

{SUB_ID_OF(GenericBlock)+} , 
{REQ  tconstraint-name  {"17"}, 
PERM  t external -data  {ANY_VALUE} } } 


117 


FOD26  Paz-t  1  -  Document  J^plication  Profile 


July  1992 


7.4.3.20     SourcedContentFized:  ANY -FRAKE -VARIABLE  { 


GENERIC : 
CASE 


$DAC  OF  { 
$PDA-FPDA: 


SPECIFIC! 
CASE 


REQ 
PERM 


REQ 
REQ 


Logical-source 
Position 


{OBJECT_CLASS_lD_OF ( CommonContent ) } , 
{REQ  ffixed-position 

{REQ  #horizontal-po8ition{ANY__VALUE}, 
REQ  #vertical-position{ANY_VALUE}>} 
CASE  SUPERIOR  (CompositeHeader | Composite footer 

(Layout -path) )  OF  { 

{ '270-degrees'} : 

REQ    Dimension        {REQ  thorizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE)}, 
REQ  #vertical -dimension 
{REQ  # fixed-dimension  {ANY__VALUE} 
I REQ  #rule-b  {ANY_VALUE>}}, 
PERM  Layout-path  {'270-degrees'} 
{ '180-degrees'} : 

REQ    Dimension       {REQ  #horizontal-dimension 

{REQ  # fixed-dimension  {ANY_yALUE} 
I  REQ  #rule-b  {ANY_VALUE}}, 
REQ  tvertical-dimension 
{REQ  # fixed-dimension  {ANY_VALUE}} , 
REQ    Layout -path  {'ISO-degrees'} 


> 

REQ  Application-comments 


$DAC  OF  { 

$FDA:    PERM  Object-class 
$FPDA:  REQ  Object-class 
>/ 

Subordinates 
Application-comments 


{REQ  #constraint-name  {"18"}, 
PERM  #external-data  {ANY_VALUE}} 


{  OB  JECT_CLASS_ID_OF 

(SourcedContentFixed) } 
{  OB  JECT_CLASS_ID_OF 

(SourcedContentFixed) } 

{SUB_ID_0F ( Specif icBlock) +} , 
{REQ  #constraint-name  {"18"}, 
PERM  #external-data  {ANY_VALUE}}} 


7.4.3.21    ArrangedContentFixed:  ANY -FRAME -FIXED  { 
GENERIC : 

CASE       $DAC  0F{ 

$PDA-FPDA: 

REQ       Generator-for-subordinates  {SEQ(OBJECT_CLASS_ID_OF 

( GenericBlock )...)}} , 
REQ       Application-comments  {REQ  #constraint-name  {"16"}, 

PERM  #external-data  {ANY_VALUE}} 
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SPECIFIC : 

CASE       $DAC  OF  { 

$FDA:    PERM  Object-class 

$FPOA:  REQ  Object-class 

REQ  Sxibordinates 

PERM  Application-comments 


{ OB JECT_CLASS_ID_OF 

(ArrangedContentFixed) } 
{  OB  JECT_CLASS_ID_OF 

(ArrangedContentFixed) } 

{SUB_ID_OF(GenericBlock)+} , 
{REQ  tconstraint-name  {"16"), 
PERM  #external-data  {ANY_VALUE}>} 


7.4.3.22 

GenericBlock:  BLOCK  { 

GENERIC : 

REQ 

object-class-identifier 

{ANY_VALUE) 

REQ 

Object-type 

{ 'block'}. 

REQ 

Content-ar  chitec  tvire  -c  las  s 

{ $FC 1 $FPC 1 $FPR 1 $FPG} , 

PERM 

Resource 

{ANY_VALUE}, 

PERM 

Content -portions 

{CONTENT_ID__OF 

PERM  User-readable-comments 
PERM  User-visible-name 
PERM  Position 


PERM  Dimension 


REQ  Application-comments 


SPECIFIC! 
CASE 


CASE 


( character-content -portion ) + 
I  CONTENT  ID_OF 

(raster-graphics -content -portion) 
I CONTENT_ID_OF 

(geometric-graphics-content -portion) } ; 
{ANy__STRING}  , 
{ANY~STRING} , 
{REQ  #fixed-position 

{REQ  #horizontal-position{ANY_VALUE}, 
REQ  #vertical-position{ANY_VALUE}}>, 
{REQ  fhorizontal-dimension 

{REQ  «fixed-dimension  {ANY_VALUE}}, 
REQ  #vertical-dimension 

{REQ  « fixed-dimension  {ANY_VALUE} } } , 
{REQ  tconstraint-name  {"29"}, 
PERM  #external-data  {ANY__VALUE}} 


$DAC  OF  { 
$FDA:  PERM 
$FPDA:  REQ 
}» 

Generic  Block  (object-class)  OF  {VOID: 


Object-class 
Object-class 


{OBJECT_CLASS_ID__OF(  GenericBlock) } 
{OBJECT_CLASS_lD_OF (GenericBlock) } 


REQ     Content -portions 


PERM  Application-comments 


{CONTENT_ID_OF 

( character-content-portion ) + , 
CONTENT_ID__OF 

( raster-graphics-content -portion ) , 
CONTENT_ID_OF 

( geometric -graphics -content -portion) } , 

}, 

{REQ '#constraint -name  {"29"}, 
PERM  #external-data  {ANY_VALUE}}} 


SPECIFIC_AND_GENERIC : 

PERM  Presentation-style 


{  STYI.E_ID_OF  ( P-Sty  le  1 ) 
STYLE_ID_OF ( P-Sty le2 ) 
STYLE  ID  OF ( P-Sty le3) } , 
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7.4.3.23  specif icBlock:  BLOCK  { 
SPECIFIC: 

PERM  Presen'tation-atyle 

REQ  Content-portions 


PERM  Application-comments 


{ STYLE_ID_OF { P-Sty le 1 ) 
STYLE_ID_OF ( P-Sty le2 ) 
STYI.E__ID__OF  ( P-Sty  le3  ) 
style~id"of ( P-Sty le4 ) } , 

{CONTENT_ID_OF 

( character-content -portion )  •f , 
CONTENT__ID_OF 

(raster-graphics-content -portion) , 
CONTENT__ID_OF 

(geometric-graphics-content -portion)  > , 

{REQ  #constraint-name  {"30"), 
PERM  #external-data  {ANy_VALUE}}} 


7.5    Layout  style  constituent  constraints 

7 .5.1    Macro  definitions 

DEFINE (LayoutobjectClasses,  " 

OB  JECT_CLASS_ID_OF  ( PageSet ) 
OB JECT_CLASS_ID_OF ( Page ) 
OBJECT_CLASS_lD_OF (RectoPage ) 
OBJECT_CLASS~ID_OF ( VeraoPage ) 
OBJECT_CIiASs"lD_OF  ( BasicBody ) 
OB  JECT__CLASS_ID__OF  ( VariableCompositeBody ) 
OB  JECT_CLASS_ID_OF  ( BasicFloat ) 
OB  JECT_CLASS_lD_OF  ( SnakingColumns ) 
OBJECT_CLASS_ID_OF  ( SynchronizedColumns ) 
OB  ject"class_id_of  ( columnFixed ) 
OBJECT~CLASS_ID_OF  ( ColumnVariable ) 


DEFINE (SameLayoutobject,  " 

REQ  #logical-object{<object-id-expr> 

I 'null'}, 
PERM  #layout-object{ 'page'} 
") 


;  =     PREC  -OBJ  ( CURR-OB J  )  ; 


7.5.2     FACTOR:  ANY-LAYOUT-STYLE  { 

REQ  Layout-style-identifier 
PERM  User-visible-name 
PERM  User-readable-comments 


{ANY__VALUE}, 
{ANY_STRING} , 
{ANY_STRING} } 
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7.5.3    Layout  style  constituent  constraints 

7.5.3.1  L-Stylel:  ANY -LAYOUT-STYLE  { 

—  this  style  is  used  for  the  constituent  Passage  only  — 

CASE  Docuinent-profile( Generic -lay out-structure)  OF  { 
{ 'complete-generator-set ' > : 

PERM  Layout -object-class  {OBJECT_CLASS_lD_OF(PageSet) ) , 
PERM  New-layout-ob j  ect  { OB JECT_CLASS_ID_OF ( PageSet ) } , 
PERM      Indivisibility  {$LayoutObjectClasses 

I ANY_STRING | ' page ' | ' null ' } 

VOID : 

PERM      Indivisibility  {ANY_STRINg| 'page' | 'null'} 

}} 

—  ANY_STRING  is  interpreted  as  representing  the  name  of  a  layout 
category  — 

7.5.3.2  L-Style2:  ANY -LAYOUT -STYLE  { 


—  this  style  is  used  for  the  constituents 
BodyText,  and  Number  — 

CASE  Document -profile (Generic-layout-structure)  OF  { 
{ 'complete-generator-set' } : 
PERM  Indivisibility 


PERM     New-layout -object 


VOID: 

PERM  Indivisibility 
PERM  New-layout-object 

PERM  Layout -category 

PERM  Same-layout-object 

PERM  Concatenation 

PERM  Offset 

PERM  Separation 

PERM  Block-alignment 
PERM  Synchronization 


{ $LayoutOb jectclasses , 

I ANY_STRING | 'page ' | ' null ' } , 
{$LayoutOb jectclasses 
|any_STRINg| 'page' | 'null'} 

{ANY_STRING  'page'  'null'}, 
{ANY_string  'page'  'null'} 
} 

{ANY__STRING}  , 
{$SameLayoutObject} , 
{ANY_VALUE}, 
{ANY~VALUE>, 

{PERM  #leading-edge{ANY_INTEGER}, 
PERM  #trailing-edge{ANY_INTEGER}}, 
{ANY__VALUE}, 
{ANY_VALUE}} 


7.5.3.3    L-Style3:  ANY -LAYOUT-STYLE  { 

—  this  style  is  used  for  the  constituents 
CommonText  and  PageNumber  — 


PERM  Concatenation 

PERM  Offset 

PERM  Block-alignment 

PERM  Separation 


{ANY_VALUE}, 
{ANY_VALUE}, 
{ANY_VALUE} , 

{PERM  # leading -edge {ANY_INTEGER}, 
PERM  #tr ailing-edge {ANY  INTEGER}}} 
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7.5.3.4    L-Style4:  ANY -LAYOUT-STYLE  { 

—  this  style  is  used  for  the  constituents  Nunberedsegment 
and  Paragraph  — 

CASE  Document-profile (Generic-layout-structure)  OF  { 
{ 'complete -generator-set ' } : 
PERM  Indivisibility 


VOID: 


PERM  Layout-object-class 
PERM     New-layout -object 


PERM  Indivisibility 
PERM  New-layout-object 


PERK  Same-layout -object 
PERM  Synchronization 


{ $LayoutOb jectClasses 

I  ANY__STRING  | '  page '  I '  null ' } , 
{OBJECT_CLASS_ID_OF ( PageSet ) } , 
{$Layoutob jectClasses 
|any_STRINg| 'page' I 'null'} 

{ANY_STRING  'page'  'null'}, 
{ANY_STRING  'page'  'null'} 
} 

{$SameLay out object} , 
{ANY_VALUE}} 


—  ANY_STRING  is  interpreted  as  representing  the  name  of  a  layout 
category 


7.5.3.5    L-Style5:  ANY -LAYOUT-STYLE  { 


—  this  style  is  used  for  the  constituents 
Body Raster  and  BodyGeometric  — 


IE  Document-profile (Generic-layout-structure)  OF  { 
{ 'complete-generator-set ' } ; 

PERM      New-layout-object        {$LayoutOb jectClasses, 

|any_STRINg| 'page' | 'null'} 

VOID: 

PERM      New-layout-object        {ANY_STRINg| 'page' | 'null'} 

> 

—  any_string  is  interpreted  as  representing  the  name  of  a  layout 
category  — 


PERM  Layout -category 

PERM  Offset 

PERM  Same-layout-object 

PERM  separation 

PERM  Block-alignment 

PERM  Synchronization 


{ANY_STRING} , 
{ANY_VALUE}, 
{$sameLayoutOb ject} , 
{PERM  # leading-edge {ANY_INTEGER}, 
PERM  #tr ailing-edge  { ANY__INTEGER}  } , 
{ANY_VALUE}, 
{ANY__VALUE}} 
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7.5.3.6    L-Style6:  ANY -LAYOUT -STYLE 

—  this  style  is  used  for  the 

REQ       Layout -category 
PERM  Concatenation 
PERM  Indivisibility 


PERM  offset 

PERM  Block-alignment 

PERM  Separation 


constituent  FootnoteText  — 

{"Footnote") , 
{ANY_VALUE}, 

{OBJECT_CLASS__lD_OF  (FootnoteArea) 

'PAGE' 

'NXJLL'}; 
{ANY_VALUE}, 
{ANY__VALUE}, 

{PERM  #leading-edge{ANY_INTEGER}, 
PERM  #trailing-edge { ANY_INTEGER} } } 


7.5.3.7    L-Style7:  ANY -LAYOUT-STYLE  { 

—  this  style  is  used  for  the  constituent  Footnote  only  — 
,  PERM     Same-layout -object  {$SameLayoutObjeot} } 


7.5.3.8    L-Style8:  ANY -LAYOUT-STYLE  { 

—  this  style  is  used  for  the  constituents 
CommonRaster  and  CoramonGeometric  — 


PERM  Offset 

PERM  Block-alignment 

PERM  Separation 


{ANY_VALUE} , 
{ANY_VALUE}, 

{PERM  #leading-edge{ANY_INTEGER} , 
PERM  #tr ailing-edge {ANY_INTEGER}  } } 


7.5.3.9    L-Style9:  ANY-LAYOUT-STYLE  { 

—  this  style  is  used  for  the  constituent  FootnoteNumber  — 


REQ  Layout -category 

PERM  Offset 

PERM  Block-alignment 

PERM  Separation 


{"Footnote"}, 
{ANY__VALUE}  , 

{ANY_VALUE} , 

{PERM  #leading-edge{ANY__INTEGER}, 
PERM  #trailing-edge { ANY_INTEGER}  } } 


7.5.3.10    L-StylelO:  ANY-LAYOUT-STYLE  { 

—  this  style  is  used  for  the  constituents 
FootnoteRef erence  only  — 

CASE  Document-prof ile(Genaric-layout-structure)  OF  { 
{ ' complete-generator-set ' } : 

PERM      Indivisibility  {$LayoutObjectClasses, 

1any_STRINg| 'page' | 'null') 

VOID? 

PERM      Indivisibility  {ANY_string| 'page ' | 'null' ) 

} 
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PERM  Layout-category  {ANy__STRING} , 

PERM  Same-layout -object  {$SaineLayoutObject} , 

PERM  concatenation  {ANY_VALUE> , 

PERM  offset  {ANY_VALUE}, 

PERM  Separation  {PERM  #leading-edge{ANT_INTE6ER}, 

PERM  #trailing-edge{ANY_I17TEGER}}, 

PERM  Block-alignment  {ANy_VALUE} 

7.5.3.11    L-Stylell:  ANy_LAyOUT_STYLE{ 

—  this  style  is  used  for  the  constituent  Footnotebody 
PERM     Same-layout -object  {$SameLayoutObject}, 
PERM      Indivisibility  {OBJECT_CLASS__ID_OF  (FootnoteArea) 

'PAGE' 
'NULL'}; 

7.6    Presentation  style  constituent  constrsdjits 

7.6.1  Macro  definitions 

No  macro  definitions  are  applicable  to  this  clause. 

7.6.2  Factor  constraints 

7.6.2.1     FACTOR:  ANY-PRESENTATION-STYLE  { 

REQ  Presentation-style-identifier  {ANy_VALUE}, 

PERM  User-visible-name  {ANY_STRING} , 

PERM  Border  {ANy_VALUE}, 

PERM  User-readable-comments  {ANY_STRING}} 


7.6.3    Presentation  style  constituent  constraints 

7.6.3.1    P-Stylel:  ANY-PRESENTATION-STYLE  { 

—  this  style  is  used  for  the  constituents  BodyText,  Number, 

FootnoteNumber,  FootnoteReference,  FootnoteText ,  GenericBlock  and 
specificBlock  — 


PERM    Presentation  attributes  { 
PERM  #character-attributes  { 
PERM  ialignment 
PERM  fcharacter-spacing 
PERM  tcheuracter-fonts 
PERM  #character-orientation 

PERM  #character-path 

PERM  #code-extension-amnouncers 

PERM  #first-line-off8et 

PERM  tgraphic -character-sets 


{any__value}, 
{any"value}, 
{any_value}, 
{ '0 -degrees' 

I '90-degrees'}, 
{ANY_VALUE>, 
'{$CDEXTAN}, 
{ANY_VALUE}, 
{$PERMIT-GRCHAR} , 
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F£RM 

tgraphic-character-siibrepertoire    {ANY_yALUE> , 

wxnQGnuciwxon 

{ANY  VAliUE }  f 

/&MV  \TaTtTP\ 
^  AM  X    WALiUCt  J  f 

/ANY  VALUE \ . 

PERM 

tline-progreasion 

{ANY~VALUE}, 

PERM 

#line-spacing 

{ANY^VALUE} , 

PERM 

#line-layout -table 

{ANY~VALUE), 

PERM 

#orphan-8ize 

{any]Value}, 

PERM 

tproportional-line-spacing 

{AMY~VALUE}, 

PERM 

#widow-size 

{ANY~VALUE>)} 

7.6.3.2     P-Style2:  ANY -PRESENTATION-STYLE  { 

—  this  style  is  used  for  the  constituents  BodyGeometric,  ConmonGeometric , 
Generic  Block  and  Specific  Block  — 


PERM    Presentation  attributes  { 

PERM  fgeometric-graphics-attributes 
PERM  #picture-dimensions 
PERM  #picture-orientation 
PERM  #text-rendition 


{ 

{ANY_VALUE} , 
{ANY_VALUE), 

{PERM  *fontS-list{ANY_VALUE}, 
PERM  #character-set-list 

{ANY_VALUE>} 


7.6.3.4    P-Style3:  ANY-PRESENTATION-STYLE  { 

—  this  style  is  used  for  the  constituents  BodyRaster,  conmonRaster,  Generic 
Block  and  Specific  Block  — 

PERM    Presentation  attributes  { 

PERM  fraster-graphics-attributes  { 

PERM  # image -dimensions  {ANY^VALUE}, 

PERM  #clipping  {ANY~VALUE}, 

PERM  #pel-spacing  {ANY_VALUE}, 

PERM  # spacing-ratio  {ANY_VALUE}}} 


7.6.3.5     P-Style4:  ANY-PRESENTATION-STYLE  { 

—  this  style  is  used  for  the  constituents  commonText,  PageNumber  and 
SpecificBlock  — 


PERM    Presentation  attributes  { 
PERM  tcheoracter-attributes  { 
PERM  falignment 
PERM  #character-spacing 
PERM  #character-fonts 
PERM  tcharacter-orientation 

PERM  #character-path 


{ANY_VALUE), 
{ANY_VALUE), 
{ANY_VALUE>, 
{ /Q-degrees' 

I '90-degrees'}, 
{ '0-degrees' 
'180-degrees' 
'270-degrees' } , 
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PERM  #code-extension-announcers  {$CDEXTAN}, 

PERM  #first-line-offset  {ANY_VALUE}, 

PERM  #graphic-character-set3  {$PERMIT-GRCHAR} , 

PERM  tgraphic-character-subrepertoire  {ANY_VALUE}, 

PERM  #graphic-rendition  { $GRAPHICRENDITIONS } , 

PERM  #indentation  {ANY_VALUE}, 

PERM  #iteniisation  {ANY_value}, 

PERM  fkerning-offset  {ANY_VALUE}, 

PERM  #line-progression  {ANY_VALUE}, 

PERM  #line-8pacing  {ANY_VALUE}, 

PERM  #line-layout-table  {ANY_VALUE}, 

PERM  #proportional-line-spacing  {ANY  VALUE)}) 


7.7    Con'tent  portion  constituent:  constraints 
7«7.1    Macro  definitions 

No  macro  definitions  are  applicable  to  this  clause. 


7.7.2    Factor  constraints 

7.7.2.1     FACTOR:  ANY-CONTENT  { 

CASE  $DAC  OF  { 
$FDA; 

REQ  Content-identifier-layout  {ANY_VALUE} 

$POA: 

REQ  Content-identifier-logical  {ANY_VALUE} 

—  This  attribute  is  specified,  if  the  content  portion  is 
associated  with  a  basic  logical  object  or  a  basic  logical 
object  class.  — 

I REQ  Content-identifier-layout  {ANY_VALUE} 

—  This  attribute  is  specified,  if  the  content  portion  is 
associated  with  a  basic  layout  object  class.  — 

$FPDA: 

REQ  Content-identifier-layout  {ANY_VALUE}, 
REQ  content-identifier-logical  {ANY_VALUE} 

—  Both  attributes  are  specified,  if  the  content  portion 
is  associated  with  a  basic  logical  object  and  a  basic 
layout  object.  — 

I  REQ  Content-identifier-layout  {ANY_VALUE} 

—  This  attribute  is  specified,  if  the  content  portion  is 
associated  with  a  basic  layout  object  class.  — 

I REQ  Content-identifier-logical  {ANY_VALUE} 

—  This  attribute  is  specified,  if  the  content  portion  is 
associated  with  a  basic  logical  object  class.  — 
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7.7.3    Content  portion  constraints 


7.7.3.1    Chcuracter-content -portion:  ANY -CONTENT  { 

PERM     Type-of -coding  {ASN.1{2  8  3  6  0}}, 

PERM     Alternative-representation        {ANY_STRING} , 
PERM  Content-information 

{CHARACTER     {#STAB  {ANY_VALUE} 

#SHS  {0,1,2,3,4} 

#SGR  {$GRAPHICRENDITIONS} 

#SVS  {ANy_VALUE} 

#SLS  {ANY_VALUE} 

#SCS  {ANY_VALUE} 

#SRS  {ANY_VALUE} 

#JFY  {0} 

#CR 

#LF 

#VPB 

#VPR 

#PLD 

#PLU 

#SP 

#SUB 

#BPH 

#NBH 

#sos 

#ST 

#LSO 

#LS1R 

#LS2R 

«LS3R 

«SS2 

#SS3 

#ESC  {  $DEG-CORE-<30  } 
#ESC { $DEG-6  4  6 -GO } 
#ESC { §DEG-ANY-G 1 } 
#ESC { $DEG-ANY-G2 } 
#ESC{$DEG-ANY-G3} 
#ESC { $DEG-EMPTY-G1 } 
}•..}} 


127 


F002S  Part;  1  -  Docunent  ii^plication  Profile 


July  1992 


7.7.3.2  Ras'ter^graphicB-content-portiont  ANY-CONTENT  { 


PERM 

REQ 

PERM 


Number-of-linea 
Number-of-pels-per-line 
Type-of -coding 


{>0}, 
{>-0), 
{ASN.1{2  8  3  7  0} 
|aSN.1{2  8  3  7  1} 


T.6  encoding  — 
T.4  one-dimensional 

encoding  — 
T.4  two  dimensional 

encoding  — 
bitmap  encoding  — }, 


|asN.1{2  8  3  7  2} 


|asN.1{2  8  3  7  3} 


PERM 
PERM 
PERM 


Compression 
Alternative-representation 
content-information 


{ANY_VALUE}, 
{ANY_STRING} , 
{RASTER}} 


7.7.3.3    Geometric-graphics-content-portion:  ANY-CONTENT 


{ 


PERM  Type-of-coding 

PERM  Alternative-representation 

PERM  Content-information 


{ASN.1{2  8  3  8 
{ANY_STRING} , 
{GEOMETRIC}} 


0}}, 


8 


Interchange  format 


For  conformance  to  this  profile,  the  interchange  format  class  A  shall  be  used 
when  applying  ODIF,  and  the  interchange  format  SDIF  shall  be  used  when  applying 
ODL  in  conjunction  with  SDIF. 


8.1    Interchange  format  class  A 

8.1.1  Interchange  format 

The  value  of  the  document  profile  attribute  "Interchange  format"  for  this 
interchange  format  is  "if -a".    This  form  of  ODIF  is  defined  in  CCITT 
Recommendation  T.415|lSO  8613-5. 

8.1.2  DAP  identifier 

The  value  for  the  document  profile  attribute  "Document  application  profile"  for 
this  interchange  format  is  represented  by  the  following  object  identifier. 


ASN.l  {2  8  4  0  26  0} 
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8.1.3    Encoding  of  application  cconments 

The  encoding  of  the  attribute  "application  comments"  is  defined  in  this  encoding 
as  an  octet  string  as  specified  in  CCITT  Recommendation  T. 415 | ISO  8613-5.  This 
document  application  profile  requires  that  the  encoding  within  that  octet  string 
be  in  accordance  with  the  ASN.l  syntax  specified  in  the  following  module 
definition : 

FOD-DAPSpecif ication 
DEFINITIONS : : «BEGIN 
EXPORTS  Appl-Comm-Encoding; 

Appl-Comm-Encoding: :=  SEQUENCE { 
constraint -name  [0]  IMPLICIT  PrintedsleString  OPTIONAL, 

external-data  [1]   IMPLICIT  OCTET  STRING  OPTIONAL  } 

END 


8.1.4    Data  lengths  . 

The  mcucimum  length  of  data  values  of  the  type  OCTET  STRING,  as  defined  in  ISO 
8824,  in  data  streams  which  may  be  encoded  in  accordance  with  this  DAP  is  32767 
octets.    If  it  is  required  to  encode  an  octet  string  of  greater  length  than 
this,  constructed  type  encoding  shall  be  used.    That  is,  data  values  greater 
than  32767  in  length  shall  be  split  into  a  sequence  of  strings  shorter  than 
32767,  each  of  which  is  encoded  using  a  primitive  type. 

8.2    Interchange  format  SDIF 

8.2.1  Interchange  format 

The  document  profile  attribute  "Interchange  format"  does  not  apply  for  this 
interchange  format.    This  form  of  ODIF  is  defined  in  Annex  E  of  CCITT 
Recommendation  T.415|lSO  8613-5.    CCITT  Recommendation  T.415|lSO  8613-6,  -7  and 
-8  contain  additional  specifications  for  interchange  format. 

8.2.2  DAP  identifier 

The  value  for  the  attribute  "Document  application  profile"  for  this  interchange 
format  is  represented  by  the  following  object  identifier. 

ASN.l  {1  0  11181  0  26  0} 

NOTE  -  There  is  no  requirement  to  include  a  part  number  arc  within  the 
object  identifier  for  the  DAP. 
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8.2.3    Encoding  of  application  camments 

The  encoding  of  the  attribute  "Application  comments"  is  defined  in  data  stream 
conforming  to  this  profile  with  this  encoding  with  the  following  DTD  definition: 

<1 — Public  docximent  type  definition.    Typical  invocation; 
<ID0CTYPE  fodapc  PUBLIC  "ISO/IEC  11181-1   ;   1992 //DTD 

Application  Comments//EN"  ["]> 


For  example,  a  typical  SUBDOC  for  representing  the  "application  comments"  of  a 
Paragraph  then  would  look  like: 

<1D0CTYPE  fodapc  PUBLIC  "ISO/IEC  11181-1  :  1992//DTD  Application  Comments/ /EN "> 
<fodapc  consname=6> 

If  the  optionality  of  the  attribute  "fodapc"  is  specified  in  an  earlier  portion 
of  the  DTD,  the  invocation  may  be  minimised  further  because  the  tag  is  not 
needed  when  "application  comments"  are  not  included  as  is  the  case  here. 

Thecontent  of  external  data  appearing  inline  is  rfestricted  to  parsable  data. 
Referenced  external  data  need  not  be  parsable. 


— > 


<1 ELEMENT  fodapc 
<1ATTLIST  fodapc 
<l ELEMENT  externl 
<IATTLIST  externl 


-0        ( externl? )> 
consname  CDATA  #IMPLIED> 
-0  (#PCDATA)> 
loc       ENTITY  #CONREF> 
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ANNEX  A 
JUnendments  and  corrigenda 

(This  annex  fona  an  integral  part  of  this  Specification.) 
A.  1  Anendnenta 

A.  1.1    Amendments  to  the  base  standard 

The  amendments  applicable  to  this  ISP  includes  the  [CCITT  Recommendation 
T.41l|lS0  8613-1]  -  Amendment  1:  1990.      This  amendment  includes  text  to  be 
included  in  [CCITT  Recommendation  T.41l|lS0  8613-1]  as  the  following  annexes: 

Annex  E:  Use  of  ISO/IEC  10021  (MOTIS)  to  inter.change  documents 
conforming  to  CCITT  Recommendation  T.415|lSO  8613; 

-  Annex  F:  Document  Application  Profile  proforma  and  notation; 
Annex  6:  Conformance  testing  methodology; 

Annex  H:  Recording  of  documents  conforming  to  [CCITT  T.410  series 
Recommendations  I ISO  8613]  on  flexible  disk  cartridges  conforming  to 
ISO  9293. 

In  addition,  this  amendment  addresses  the  inclusion  of  the  CCITT  T.410  series 
Recommendations  I  ISO  8613  Technical  Corregenda  1. 

This  ISP  does  not  include  the  following  features  of  the  amendment: 
Addendum  on  security; 
Addendum  on  styles; 

Addendum  on  alternative  representation. 
Addendum  on  colour; 

-  Addendum  on  tiled  raster  graphics 

A.  1.2    Proposed  changes  to  standards  due  to  defects 

Proposed  Technical  Corrigendum  No.  44  to  [CCITT  T.410  series  Recommendations] 
ISO  8613]  dated  15  December  1991  assumed  to  be  ratified  by  ISO. 

A.  2  Corrigenda 

A. 2.1    Corrigenda  to  the  ISP 

There  is  no  corrigendum  specific  to  this  ISP. 
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AHNEX  B 
RecGognnendatlonB 


(This  annex  does  not  form  an  integral  part  of  this  Specif leatJAn. ) 


B.l    Transfer  aethoda  for  ODA 


B.1.1    Conveyance  of  ODK  over  CCITT  Z. 400-1984 

This  recommendation  describes  how  ODA  body  parts  are  to  be  encoded  for 
transmission  over  a  CCITT  X. 400-1984  service. 

* 

An  ODA  body  part  is  encoded  as  odaBodyPart  in  the  definition  given  below t 

odaBodyPart  : : =  SEQUENCE  {  odaBodyPartParameters ,  OdaOata  } 
OdaBodyPartParameter s  : : "  SET  { 

document-application-profile 

[0]   IMPLICIT  OBJECT  IDENTIFER, 
document -architecture-class 
[1]   IMPLICIT  INTEGER  { 
formatted  (0), 
processable  (1), 
f ormatted-processable  ( 2 )  } 
odaData  ::sSEQUENCE  OF  Interchange-Data-Element 

NOTE  -  It  is  recommended  to  transfer  an  ODA  document  as  a  single  body  part 
with  tag  12: 

Oda  [12]   IMPLICIT  OCTETSTRING 

The  content  of  the  octet  string  is  encoded  as  OdaBodyPart,  defined  above. 
However,  this  is  out  of  the  scope  of  this  profile. 


B.l. 2    Conveyance  of  ODA  over  FT^ 

This  recommendation  describes  the  FTAM  Document  Type  to  be  used  for  minimal 
storage  and  transfer  capabilities  of  ODA  data  streams.    It  is  recognized  that 
enhanced  capabilities  may  at  some  point  be  added. 

When  using  FTAM  to  transfer  an  ODA  file,  the  FTAH-3,  "ISO  FTAM  Unstructured 
Binetry",  document  type  shall  be  specified. 
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However,  since  files  that  do  not  contain  ODA  data  streams  can  have  the  same 
document  type,  it  is  left  up  to  the  user  of  application  programs  that  remotely 
access  files  using  FTAM  to  know  that  a  given  file  contains  an  ODA  data  stream. 

B.1.3    Conveyance  of  ODA  over  DTAN 

This  recommendation  provides  for  information  concerning  the  interchange  of  ODA 
based  documents  with  DTAM  protocols. 

DTAM  (Document  Transfer  and  Manipulation)  is  defined  in  the  T.430-Series  of 
recommendations  and  is,  like  ODA,  an  integral  part  of  the  T.400-Series  of  CCITT 
Recommendations  named  Open  Document  Architecture,  Transfer  and  Manipulation. 

The  T.520-series  of  reconunendations  contain  Communication  Application  Profiles 
(CAP).    Recommendation  T.522  describes  the  Communication  Application  Profile  BTl 
for  document  bulk  transfer.    Recommendation  T.522  is  applicedsle  for  the  Office 
Document  Format  Profile  (FOD)  published  in  this  ISP. 

NOTE  -  The  use  of  BTl  within  the  end-to-end  oriented  Telematic  Services 
Telefax  4  and  Teletex  is  described  in  Recommendation  T.561,  subclause  7.1 
and  Recommendation  T.562,  subclause  7.1. 


B.1.4    Conveyance  of  ODA  over  flexible  dislcs 

The  recommended  method  for  interchanging  ODA  documents  between  systems  by  the 
exchange  of  magnetically  recorded  Flexible  Disk  Cartridges  is  by  the  use  of  an 
annex  to  ISO  8613-1  (to  be  published),  "Recording  of  Documents  Conforming  to 
ISO  8613  on  Flexible  Cartridges  Conforming  to  ISO  9293",    This  annex  provides 
for  recording  each  ODA  document  as  a  separate  file  as  defined  by  ISO  9293, 
"Volume  and  File  Structure  of  Flexible  Disk  Cartridges  for  Information 
Interchange" . 

NOTE  -  Documents  encoded  in  ODL  may  be  stored  such  that  each  SGML  ENTITY  is 
recorded  in  a  separate  file  or  in  the  case  of  an  SDIF  encoding,  the  file 
may  be  stored  in  a  single  file. 

B.2    Font  reference 

The  recommended  method  for  specifying  a  font  reference  is  to  be  based  on  ISO 
9541. 
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Font  sizes  from  6  to  72  points  (100  to  1200  BMU)  are  intended  to  be  supported  by 
implementation  conforming  to  this  recommendation.    All  other  values  of  font 
sizes  may  additionally  be  supported,  but  implementations  may  also  support  using 
some  form  of  "fallback". 


The  minimum  font  properties  and  values  from  ISO  9541  that  are  to  be  specified  in 
a  Font>Attribute-set  be  those  specified  by  the  following  document  application 
profile  notation. 

Font-Attribute-Set{ 


PERM 
PERM 
PERM 
PERM 
PERM 
PERM 
PERM 
PERM 


PERM 
PERM 


PERM 


PERM 


PERM 
PERM 


Fontname 

Standard-Version 
Design-Source 
Font-Family-Name 
Posture 
Height 

Proportionate -Width 
Glyph-Complement  { 
PERM  #Included-Glyph-Collections 

{ANy__VALUE}, 
PERM  #Excluded-Glyph-Collections 

{ANY_VALUE}, 

PERM  fIncluded-Glyphs 
PERM  #Excluded-Glyphs 


{ANY__VALUE}, 
{ANY_VALUE), 
{ANY^VALUE}, 
{ANY_VALUE}, 

{ ' upright '  |   ' it alio -forward ' > , 
{'light'  I   'medium'  |  'bold'}, 
{ANY_VALUE}, 


{ANY_VALUE), 
{ANy~VALUE} 


Design-Size 
Min-Size 
PERM  #Kumerator 
PERM  #Denominator 

Max-Size 
PERM  #Numerator 
PERM  iDenominator 


{ 


{ 


{ANY_VALUE}, 

{100  ..  1200}, 
{1}  . 


{100 
{1} 


1200}, 


—  BMU  Units  equivalent  to  range  of  6.. 72  point  sizes  — 


Design-Group 
PERM  #class 
PERM  isubclass 
PERM  tspecif ic-Group 


{ 


} 


{ANY_VALUE}, 
{ANY_VALUE}, 
{ANY_VALUE} 

{ANY_VALUE}, 


Structure 
Writing-Modes  { 
MUL 

PERM  #Wri ting-Mode -Name 
PERM  #Nominal-Escapement-Direction 

{ANY_VALUE}, 

PERM  lEscapement -Class 
PERM  #Average-E3capement-X 
PERM  #Average-Escapement-Y 

} 

} 


{ 

{ANY  VALUE}, 


{ANY_VALUE}, 
{ANY_VALUE} , 
{ANY_VALUE} 
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B.3    ISO  8632  (CGM)  conatrainta  for  thia  DAP 

It  ia  recomnended  that  geometric  graphics  content  information  contain  only  those 
elements  listed  in  this  portion  of  the  document,  in  addition  to  the  constraints 
imposed  by  CCITT  Recommendation  T.415|lSO  8613-8.    It  is  believed  that  this 
subset  of  the  C6H  ia  aufficiently  implemented  to  enable  interworking  of 
geometric  graphica  for  application  conforming  to  this  document  application 
profile . 

where  an  element  has  parameters,  recommended  constraints  on  the  values  are 
given.    The  «<— "  symbol  indicates  that  there  is  no  recommended  constraint. 

Requirements  in  ISO  8632  and  CCITT  Recommendation  T.415|lSO  8613-8  concerning 
mandatory  elements,  psurameters  shall  be  fulfilled. 


B.3.1    Deliaeter  elements 
No-op 


Begin  Metafile 


End  Metafile 
Begin  Picture 


Begin  Picture  Body 
End  Picture 


An  arbitrary  sequence  of  n  octets.  Where 

n=0,  1,....,  32  767.     The  sequence  of 

zero  or  more  octets  is  for  padding  purposes. 

Support  will  be  provided  for  strings  with  a 
length  up  to  254  octets,  except  for  data 
records  which  will  support  strings  with  a 
length  up  to  32  767  octets. 


Support  will  be  provided  for  strings  with  a 
length  up  to  254  octets,  except  for  data 
records  which  will  support  strings  with  a 
length  up  to  32  767  octets. 


B.3. 2    Metafile  descriptor  elements 

Metafile  Version  1 

Metafile  Description  support  will  be  provided  for  strings  with  a 

length  up  to  254  octets,  except  for  data 
records  which  will  support  strings  with  a 
length  up  to  32  767  octets.     The  METAFILE 
DESCRIPTION  string  parameter  will  be  used  to 
include  the  sub-string  "ISO  FOD26"  to  label 
the  content  information  as  conforming  to 
this  profile.     In  addition,  generators  of 
content  are  encouraged  to  append  a  sub- 
string that  identifies  the  company  and 
product  that  produced  the  CGM. 
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VDC  Type  Integer 

Integer  Precision  16  |^ 

Real  Precision  (0,9,23),   (1,16,16)  ^ 

Index  Precision  16 

Colour  Precision  8,  16 

Colour  Index  Precision  8,  16 

Maximum  Colour  Index  0  . .  63 

Colour  Value  Extent 

Metafile  Element  List 

Metafile  Defaults  Replacement  — 

Font  List  All  fonts  referenced  in  the  metafile  shall 

be  defined.    Font  referencing  in  FONT  LISTS 
using  ISO  9541  names  is  preferred,  but  font 
names  may  be  specified  using  proprietary 
font  names . 

Character  Set  list  All  character  sets  referenced  in  the 

metafile  shall  be  defined  in  CHARACTER  SET 
LIST.    Permissible  character  sets  are  the 
same  as  for  chcuracter  content  architecture. 

CHaracter  Coding  Announcer  — 


B.3.3    Picture  descriptor  elements 


Scaling  Mode  The  Scale  Factor  parameter  of  SCALING  MODE 

element  is  always  a  32-bit  floating  point 
value,  even  when  the  REAL  PRECISION  has 
selected  fixed  point  for  other  real  numbers. 
It  is  not  apparent  in  ISO  8632  what  the 
precision  of  this  floating  point  value  is 
when  fixed  point  has  been  selected.  Its 
precision  shall  be  (0,9,23). 

Colour  Selection  Mode  Indexed 

Line  Width  Specification  Mode  Scaled 

Marker  Size  specification 

Mode  scaled 

Edge  Width  Specification  Mode  Scaled 

VDC  Extent 

Background  Colour  — 


B.3.4    Control  elements 

VDC  Integer  Precision  16 

VDC  Real  Precision  (0,9,23),  (1,16,16) 

Auxiliary  Colour 

Transparency  Trauisparent 
Clip  Rectangle 

Clip  Indicator  — 
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B.3.5    Graphical  prijaitive  eleoients 

Polyline  support  for  point  lists  with  up  to  255 

vertices . 

Disjoint  Polyline  Support  for  point  lists  with  up  to  255 

vertices . 

Polymarker  support  for  point  lists  with  up  to  255 

vertices . 

Text  Support  will  be  provided  for  strings  with  a 

length  up  to  254  octets,  except  for  data 
records  which  will  support  strings  with  a 
length  up  to  32  767  octets.  Format  effector 
control  characters  are  disallowed  in  the 
string  ptorameter. 

Restricted  Text  support  will  be  provided  for  strings  with  a 

length  up  to  254  octets,  except  for  data 
records  which  will  support  strings  with  a 
length  up  to  32  767,  octets.  Format  effector 
control  characters  are  disallowed  in  the 
string  parameter. 

Append  Text  support  will  be  provided  for  strings  with  a 

length  up  to  254  octets,  except  for  data 
records  which  will  support  strings  with  a 
length  up  to  32  767  octets.  Format  effector 
control  characters  are  disallowed  in  the 
string  parameter. 

Polygon  support  for  point  lists  with  up  to  255 

vertices. 

Polygon  Set  support  for  point  lists  with  up  to  255 

vertices . 

Cell  Array 

Rectangle  — 
Circle 

circular  Arc  3  Point 
circular  Arc  3  Point  close 
Circular  Arc  Centre 
circular  Arc  Centre  close 
Ellipse 

Elliptical  Arc 
Elliptical  Arc  close 
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B.3.6    Attribute  elenents 


Line  Bundle  index 
Line  Type 
Line  Width 
Line  colour 
Marker  Bundle  Index 
Marker  Type 
Marker  size 
Marker  Colour 
Text  Bundle  Index 
Text  Font  Index 


Text  Precision 
character  Expansion  Factor 
Chauracter  Spacing 
Text  Colour 
character  Height 
Character  orientation 
Text  Alignment 
Character  set  Index 


1 

1-5 


1 

1-5 


All  fonts  referenced  (indexed  by  TEXT  FONT 

INDEX)  in  the  metafile  shall  be  defined  in 

FONT  LIST  either  in  presentation  parameters 

of  ISO  8613  or  in  ISO  8632. 

0  (string) 

1.0 

0.0 


Alternate  character  Set  index 


Fill  Bundle  Index 
Interior  Style 
Fill  Colour 
Batch  Index 
Pattern  Index 
Edge  Bundle  Index 
Edge  Type 
Edge  Width 
Edge  Colour 
Edge  visibility 
Fill  Reference  Point 


All  character  sets  referenced  in  the 
metafile  (indexed  by  CHARACTER  SET  INDEX) 
shall  be  defined  in  CHARACTER  SET  LIST.  The 
only  character  sets  which  nay  be  designated 
in  60  are  ISO  646  IRV  or  versions  of  ISO 
646.    Other  character  sets  shall  be 
designated  in  Gl,  G2  or  G3. 
All  character  sets  referenced  in  the 
metafile  (indexed  by  ALTERNATE  CHARACTER  SET 
INDEX)  shall  be  defined  in  CHARACTER  SET 
LIST. 

1 


1 
1 
1 

1.0 

0  (off) 
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Pattern  Teible  The  pattern  table  element  has  an  unspecified 

effect  when  it  appears  in  a  picture 
subsequent  to  any  graphical  primitives .  The 
PATTERN  TABLE  element  shall  appear  prior  to 
any  graphical  primitive  element  to  assure 
that  interpreting  systems  without  dynamic 
pattern  update  cein  render  the  intended 
effect.     The  minimum  support  for  the  length 
of  the  Colour  Array  pareuneter  for  the 
PATTERN  TABLE  element  is  2  048.     This  will 
support  8  patterns  of  16x16,  2  patterns  of 
32x32  or  1  pattern  of  32x64.    All  indexes 
whch  are  used  in  the  metafile  shall  be 
defined. 

Pattern  size 

Colour  Table  Specification       The  COLOUR  TABLE  element  has  an  unspecified 

effect  when  it  appears  in  a  picture 
subsequent  to  any  graphical  primitives.  The 
COLOUR  TABLE  element  shall  appear  prior  to 
any  graphical  primi,tive  elements  to  assure 
that  interpreting  systems  without  dynamic 
colour  update  can  render  the  intended 
effect.     The  minimum  support  for  the  length 
of  the  Colour  List  parameter  in  the  COLOUR 
TABLE  element  is  63.      This  will  support  a 
64  (0..63)  entry  colour  table.     All  indexes 
which  are  used  in  the  metafile  shall  be 
defined. 

Aspect  Source  Flags  individuals 

B.3.7    External  elements 

Message  The  presentation  of  message  string  may  not 

be  appropriate  for  all  applications .  No 
requirement  for  the  formatted  presentation 
of  the  message  string  has  been  placed  on  the 
Interpreter.     Only  the  No  Action  flag  needs 
to  be  supported.     Support  for  string  lengths 
up  to  254. 

Application  Data  support  will  be  provided  for  strings  with  a 

length  up  to  254  octets,  except  for  data 
records  which  will  support  strings  with  a 
length  up  to  32  767  octets. 


B.4    Interoperability  with  SGML  applications 

The  recommended  method  for  the  exchange  of  documents  between  Standard 
Generalized  Markup  Language  (ISO  8879,  SGI^)  based  systems  and  systems  based  on 
this  ODA  document  application  profile  is  by  means  of  exchanging  a  document 
representation  conforming  to  these  agreements  in  an  encoded  form  of  the  SGML 
language  known  as  the  Office  Document  Language  (ODL) .    ODL  is  a  standardized 
SGML  application  for  representing  documents  conforming  to  the  ODA  base  standard. 
Such  a  representation  may  be  converted  into  the  office  Document  interchange 
Format  (ODIF)  supported  by  this  document  application  profile. 
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18  Network  Management 


0  Introduction 

Within  the  community  of  OSI  researchers,  users,  and  vendors,  there  is  a  recognized  need  to  address  the 
problems  of  initiating,  terminating,  monitoring,  and  controlling  communication  activities  and  assisting  in  their 
harmonious  operation,  as  well  as  handling  abnormal  conditions.  The  activities  that  address  these  problems 
are  collectively  called  network  management. 

Network  management  can  be  viewed  as  the  set  of  operational  and  administrative  mechanisms  necessary  to: 

a.  bring  up,  enroll,  and/or  alter  network  resources; 

b.  keep  network  resources  operational; 

c.  fine  tune  these  resources  and/or  plan  for  their  expansion; 

d.  manage  the  accounting  of  their  usage; 

e.  manage  their  protection  from  unauthorized  use/tampering. 

As  such,  network  management  is  typically  concerned  with  management  activities  in  at  least  the  following  five 
functional  areas:  configuration  management,  fault  management,  performance  management,  accounting 
management,  and  security  management.  In  order  to  accomplish  these  management  activities,  information 
must  be  exchanged  among  open  systems. 

In  Part  18,  there  are  Implementation  Agreements  (lA's)  for  providing  interoperable  OSI  management 
information  communication  sen/ices  among  OSI  systems.  Also  contained  here  are  agreements  on 
management  information.  These  agreements  pertain  to  the  exchange  of  management  information  and 
management  commands  between  open  systems  operating  in  a  multivendor  environment.  For  example,  one 
goal  is  to  ensure  that  a  management  system  built  by  one  vendor  can  manage  objects  built  by  another  vendor. 
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1  Scope 

The  purpose  of  this  Part  (Part  18).  is  to  provide  impiementation  agreements  that  will  enable  independent 
vendors  to  supply  customers  with  a  diverse  set  of  networking  products  that  can  be  managed  as  part  of  an 
integrated  environment.  Where  possible,  these  agreements  are  based  upon  OSI  Systems  Management 
standards. 


1.1       Phased  Approach 

Because  of  the  broad  scope  of  the  subject,  and  given  that  OSI  Systems  Management  standards  are  still 
evolving,  it  is  reasonable  to  assume  that  a  comprehensive  set  of  network  management  implementation 
agreements  will  take  a  number  of  years  to  develop.  To  arrive  at  an  initial  set  of  implementation  agreements 
in  a  timely  fashion,  a  phased  approach  has  been  adopted. 

This  phased  work  approach  will  result  in  a  series  of  implementation  agreements  based  on  the  expanding  scope 
of  the  OSI  Systems  Management  standards.  It  is  the  intention  of  the  NMSIG  to  define  the  content  of  each 
phase  as  a  compatible  superset  of  the  previous  Phases  to  ensure  that  Phase  N  products  can  interact  with 
products  t>ased  on  the  implementation  agreements  of  earlier  phases. 


1.1.1        Alignment  With  EvoSvIng  Standards 

In  some  cases,  these  phased  implementation  agreements  may  be  based  on  DIS  standards.  As  the  relevant 
standards  progress  from  DIS  to  IS,  the  agreements  will  be  aligned  in  future  phases. 

When  a  defect  is  found  in  any  of  the  management  related  standards,  the  reported  defect  may  be  technically 
resolved  by  the  appropriate  international  technical  committee  with  likely  approval  by  the  voting  members 
pending  for  several  months.  Since  relevant  defects  can't  be  ignored  in  an  implementation,  these  agreements 
will  note  defect  resolutions  which  have  the  tentative  approval  of  the  appropriate  standards  committee.  These 
interim  resolutions  will  be  recorded  in  clause  4. 

Once  a  defect  resolution  has  been  completed  by  the  appropriate  standards  body,  the  agreed  upon  resolution 
will  be  incorporated  into  the  next  phase  of  these  implementors  agreements.  If  appropriate,  a  previous  phase 
that  relied  on  an  interim  resolution  will  be  examined  to  determine  whether  errata  should  be  issued  to  bring  the 
original  phase  into  line  with  the  final  resolution. 


1.1.2        Definition  of  Phase  1 

As  a  first  step  in  this  phased  approach,  the  NMSIG  has  targeted  an  initial  set  of  agreements  that  provide  limited 
interoperable  management  in  a  heterogeneous  vendor  environment.  They  are  the  beginning  of  a 
comprehensive  set  of  implementation  agreements  based  on  the  emerging  OSI  Systems  Management 
standards.  Furthermore,  these  initial  agreements  allow  the  community  to  gain  experience  with  OSI 
management  standards  as  they  emerge. 
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The  focus  of  the  Phase  1  agreements  is  to  enable  a  managing  process  provided  by  one  vendor  to  Interoperate 
with  an  agent  process  provided  by  a  different  vendor  to  perform  limited  management  on  a  set  of  managed 
objects. 

The  scope  of  Phase  1  implementation  agreements  is  the  following: 

Management  Functions: 

Object  Management  Function  [OMF], 

State  Management  Function  [STMF], 

Attributes  For  Representing  Relationships  [ARR], 

Alarm  Reporting  Function  [ARF], 

Event  Report  Management  Function  [ERMFj. 

Management  Information: 

Information  Model,  Naming,  Guidelines  and  Templates  for  Defining  Managed  Objects 
Management  Communication: 

CMIS/P,  Association  Policies,  and  Upper  Layer  Services  Required 
Management  Objects: 

Support  Objects  required  for  the  above. 

Editor's  Note:  [The  relation  of  the  MIL  definitions  in  Annex  A  of  the  Working  Document  to  Phase 
1  lA's  needs  to  be  clarified.] 

Conformance  Criteria: 

Conformance  Criteria  for  the  above  functionality. 

To  accomplish  these  goals  in  a  timely  fashion,  the  following  simplifying  constraints  have  been  reflected  in  the 
Phase  1  agreements: 

1.  No  agreements  are  provided  regarding  management  domains; 

2.  These  agreements  require  only  the  following  application  service  elements:  the  Association 
Control  Service  Element  (ACSE),  the  Common  Management  Information  Service  Element 
(CMISE),  Remote  Operations  Sen/ice  Element  (ROSE),  and  the  System  Management  Application 
Service  Element  (SMASE); 

3.  These  agreements  do  not  require  implementation  of  services  defined  by  the  Directory  standards; 
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4.   No  agreements  regarding  the  security  of  management  are  provided. 


1.1.3       Future  Phases 

It  is  tlie  intention  of  the  NMSIG  to  freeze  the  content  of  Phase  1  when  these  agreements  are  progressed  to 
Stabie  status.  Alignment  changes  required  as  the  standards  progress  from  DiS  to  IS  will  be  made  in  future 

phases. 

/'     As  standards  defining  new  functionality  are  progressed,  the  NMSIG  will  define  future  phases  incorporating  the 
new  functionality  as  a  compatible  superset  of  previous  phases. 


2    Normative  References 


The  following  documents  are  referenced  in  the  statements  of  the  agreements  relating  to  OSI  systems 
management. 

Editor's  Note:  [Items  marked  with  an  asterisk,  "*",  are  ones  which,  while  not  cited  in  the  text  of  this  part 
of  the  lAs,  are  included  here,  nevertheless,  to  indicate  where  useful  background  information 
can  be  found.] 

[ACSEP]  ISO  8650,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Protocol 
Specification  for  the  Association  Control  Service  Element  (Revised  Final  Text  of  DIS  8650), 
ISO/IEC  JTC1/SC21  N2327,  21  April  1988. 


[ACSES]*  ISO  8649,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Service 
Definition  for  the  Association  Control  Service  Element  (Revised  Final  Text  of  DIS  8649), 
ISO/IEC  JTC1/SC21  N2326,  21  April  1988. 

[ADDRMVP]  ISO/IEC  9596/DAD  2,  Common  Management  Information  Protocol  Specification:  Addendum 
2  (Add/Remove  Protocol).  ISO/IEC  JTC1/SC21, 1  February  1990. 

[ADDRMVS]  ISO/IEC  9595/DAD  2,  Common  Management  Information  Service  Definition:  Addendum  2 
(Add/Remove  Service),  ISO/IEC  JTC1/SC21, 1  February  1990. 

[ALS]*  ISO/IEC  DIS  9545,  Information  Processing  Systems  -  Open  Systems  Interconnection  - 

Application  Layer  Structure,  15  March  1989. 

[A0M1  PTl  ]  ISO/IEC  ISP  1 1 1 83-1 .  Information  Technology  -  International  Standardized  Profiles  A0M1  n 
OSI  Management  -  Management  Communications  -  Part  1:  Specification  of  ACSE, 
Presentation  and  Session  Protocols  for  the  use  by  ROSE  and  CMISE,  May  1992. 

[A0M1PT3]  ISO/IEC  ISP  1 1 183-3,  Information  Technology  -  International  Standardized  Profiles  AOMIn 
OSI  Management  -  Management  Communications  -  Part  3:  CMISE/ROSEfor  A0M11  -  Basic 
Management  Communications,  May  1992. 
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(A0M1 PT2]  ISO/IEC  ISP  1 1 1 83-2,  Information  Technology  -  International  Standardized  Profiles  A0M1  n 
OSI  Management  -  Management  Communications  -  Part  2:  CMISE/ROSE  for  A0M12  - 
Enhanced  Management  Communications,  May  1992. 

[A0M21 1]  pDISP  12060-1 ,  Information  Technology  -  International  Standardized  Profiles  -  A0M2n  OSI 
Management  -  Management  Functions  -  Part  1 :  A0M21 1  -  General  Management  Capabilities, 
July  1992. 

[AOM212]  pDlSP  12060-2,  Information  Technology  -  International  Standardized  Profiles  -  A0M2n  OSI 
Management  -  Management  Functions  -  Part  2:  AOM212  -  Alarm  Reporting  and  State 
Management  Capabilities,  July  1992. 

[AOM213]  pDISP  12060-3,  Information  Technology  -  International  Standardized  Profiles  -  A0M2n  OSI 
Management  -  Management  Functions  -  Part  3:  A0M21 3  -  Alarm  Reporting  Capabilities,  July 
1992. 

[AOM221  ]  pDISP  1 2060-4,  Information  Technology  -  International  Standardized  Profiles  -  A0M2nn  OSI 
Management  -  Management  Functions  -  Part  4:  AOM221  -  General  Event  Report 
Management,  July  1992. 

[AOM231]  pDISP  12060-5,  Information  Technology  -  International  Standardized  Profiles  -  A0M2n  OSI 
Management  -  Management  Functions  -  Part  5:  AOM231  -  General  Log  Control  Profile,  July 
1992. 

[ARF]  ISO/IEC  IS  10164-4,  Information  Technology  -  Open  Systems  Interconnection  -  Systems 

Management  -  Part  4:  Alarm  Reporting  Function,  ISO/IEC  JTC1/SC21  N6359,  August  19, 
1991. 

[ARR]  ISO/IEC  IS  10164-3,  Information  Technology  -  Open  Systems  Interconnection  -  Systems 

Management -Part  3:  Attributes  for  Representing  Relationships,  ISO/IEC  JTC1/SC21  N5186, 
September  1991. 

[ASN1]*  ISO/IEC  8824,  Information  Technology  -  Open  System  Interconnection  -  Specification  of 
Abstract  Syntax  Notation  One  (ASN.I),  ISO/IEC  JTC1/SC21  N4720,  30  April  1990. 

[BER]  ISO/IEC  8825,  Information  Technology  -  Open  Systems  Interconnection  -  Specification  of 

Basic  Encoding  Rules  for  Abstract  Syntax  Notation  One  (ASN.  1 ),  ISO/IEC  JTCl  /SC21  N4721 , 
30  April  1990. 

[CANGETP]  ISO/IEC  9596/DAD 1 .  Common  Management  Information  Protocol  Specification:  Addendum 
1  (CancelGet  Protocol),  ISO/IEC  JTCl /SC21, 1  February  1990. 

[CANGETS]  ISO/IEC  9595/DAD  1,  Common  Management  Information  Service  Definition:  Addendum  1 
(CancelGet  Service),  ISO/IEC  JTCl /SC21, 1  February  1990. 
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[CMIP]  ISO/IEC  9596-1,  Information  Technology  -  Open  Systems  Interconnection  -  Common 

Management  Information  Protocol  Specification  -  Part  1 :  Specification,  24  November  1990. 

[CMIS]  ISO/IEC  9595,  Information  Technology  -   Open  Systems  Interconnection  -  Common 

Management  Information  Service  Definition,  Common  Management  Information  Service,  24 
November  1990. 

[DIR]*  ISO  9594  -  Information  Processing  Systems  -  Open  Systems  Interconnection  -  The  Directory, 

1988. 

[DMI]  ISO/IEC  IS  10165-2,  Information  Technology  -  Open  Systems  Interconnection  -  Structure  of 

Management  Information  -  Part  2:  Definition  of  Management  Information,  ISO/IEC 
JTC1  /SC21  N6363,  August  1 991 . 

[ENSCON]*  Forum  025,  The  "Ensemble"  Concepts  and  Format,  Issue  1 .0,  Network  Management  Forum, 
July  1992. 

[ERMF]  ISO/IEC  IS  10164-5,  Information  Technology  -  Open  Systems  Interconnection  -  Systems 

Management  -  Part  5:  Event  Report  Management  Function,  ISO/IEC  JTC1/SC21  N6360, 
August  1991. 

[FRMWK]*  ISO  7498-4,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Basic 
Reference  Model  -  Part  4:  Management  Framework,  1989. 

[GDMO]  ISO/IEC  IS  10165-4,  Information  Technology  -  Open  Systems  Interconnection  -  Structure  of 

Management  Information  -  Part  4:  Guidelines  for  the  Definition  of  Managed  Objects,  ISO/IEC 
JTC1/SC21  N6309,  July  30,  1991. 

[ISPARR3]  pDISP  12059-3,  Information  Technology  -  International  Standardized  Profiles  -  OSI 
Management  -  Common  Information  for  Management  Functions  -  Part  3:  Attributes  for 
Representing  Relationships,  July  1992. 

[ISPAR4]  pDISP  12059-4,  Information  Technology  -  International  Standardized  Profiles  -  OSI 
Management  -  Common  Information  for  Management  Functions  -  Part  4:  Alarm  Reporting, 
July  1992. 

[ISPCOMO]  pDISP  12059-0,  Information  Technology  -  International  Standardized  Profiles  -  OSI 
Management  -  Common  I nformation  for  Management  Functions  -  Part  0:  Common  Definitions 
for  Management  Function  Profiles,  July  1992. 

[ISPERM5]  pDISP  12059-5,  Information  Technology  -  International  Standardized  Profiles  -  OSI 
Management  -  Common  Information  for  Management  Functions  -  Part  5:  Event  Report 
Management,  July  1992. 

[ISPFRM]  ISO/IEC  TR  10000-1 ,  Information  Technology  -  Framework  and  Taxonomy  of  International 
Standardized  Profiles  -  Part  1:  Framework.  ISO/IEC  JTCl/SGFS  N184,  9  February  1990. 
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[ISPLC6]  pDISP  12059-6,  Information  Technology  -  International  Standardized  Profiles  -  OSI 
Management  -  Common  Information  for  Management  Functions  -  Part  6:  Log  Control,  July 
1992. 

[ISP0M1]  pDISP  12059-1,  Information  Technology  -  International  Standardized  Profiles  -  OSI 
Management  -  Common  Information  for  Management  Functions  -  Part  1:  Object 
Management,  July  1992. 

[ISPSRVCl  ISO/IECTR  8509,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Sen/ice 
Conventions.  TC97/SC16/1646. 

[ISPSTM2]  pDISP  12059-2,  Information  Technology  -  International  Standardized  Profiles  -  OSI 
Management  -  Common  Information  for  Management  Functions  -  Part  2:  State  Management, 
July  1992. 

[LCF]  I  SO/I  EC  IS  10164-6,  Information  Technology  -  Open  Systems  Interconnection  -  Systems 

Management  -  Part  6:  Log  Control  Function,  ISO/IEC  JTC1/SC21  N6361,  June  1991. 

[MGNM]*  CCITT  Recommendation  M.gnm,  Draft  Recommendation  (M.gnm)  Generic  Network 
Information  Model.  CCITT  SGIV,  Decembers.  1991. 

IMIM]  ISO/IEC  IS  10165-1.  Information  Technology -Open  Systems  Interconnection -Management 

Information  Services  -  Structure  of  Management  Information  -  Part  1:  Management 
Information  Model.  ISO/IEC  JTC1/SC21  N6351.  June  1991. 

[NMSIG1]  OIW  Endorsement/Comment  on  System  Management  Function  Taxonomy  (Including 
Proposed  Function  Taxonomy).  NMSIG-91/164,  September  1991. 

[OMF]  ISO/IEC  IS  10164-1,  Information  Technology  -  Open  Systems  Interconnection  -  Systems 

Management  -  Part  1 :  Object  Management  Function,  ISO/IECJTCl  /SC21 N5184,  September 
1991. 

[0P1LIB]*  Forum  006.  Forum  Library  -  Volume  4:  OMNIPoint  1  Definitions,  Issue  1.0.  Network 
Management  Forum.  August  1992. 

(PPSl*  ISO/IEC  DIS  8823,  Information  Processing  Systems  -  Open  Systems  Interconnection  - 

Connection  Oriented  Presentation  Protocol  Specification.  ISO/IECJTCl  /SC21  N2336, 5 April 
1988. 

[PSD]*  ISO/IEC  Final  Text  of  DIS  8822,  Information  Processing  Systems  -  Open  Systems 

Interconnection  -  Connection  Oriented  Presentation  Service  Definition.  ISO/IEC  JTCl  /SC21 
N2335,  5April  1988. 

[ROSEP]*  ISO/IEC  9072-2  -  Information  Processing  Systems  -  Text  Communications  -  Remote 
Operations  Part  2:  Protocol  Specification,  19  September  1989. 
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[ROSES]*       ISO/IEC  9072-1,  Information  Processing  Systems  -  Text  Communications  -  Remote 
Operations  Part  1 :  Model,  Notation  and  Service  Definition,  19  September  1989. 

[SARF]  ISO/IEC  IS  10164-7,  Information  Technology  -  Open  Systems  Interconnection  -  Systems 

Management  -  Part  7:  Security  Alarm  Reporting  Function,  July  1991 . 

[SATF]  ISO/IEC  DIS  10164-8,  Information  Technology  -  Open  Systems  Interconnection  -  Systems 

Management  -  Part  8:  Security  Audit  Trail  Function,  ISO/IEC  JTCl  /SC21  N7039,  June  1 992. 

[SMO]  ISO/IEC  IS  10040,  Information  Technology  -  Open  Systems  Interconnection  -  Systems 

Management  Overview,  ISO/IEC  JTC1/SC21  N6353,  August  1991. 

[STMF]  ISO/IEC  IS  10164-2,  Information  Technology  -  Open  Systems  Interconnection  -  Systems 

Management  -  Part  2:  State  Management  Function,  ISO/IEC  JTCl  /SC21  N5185,  September 
1991. 
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3  Status 

As  of  September  1991 ,  the  Stable  management  communications  agreements  in  clause  6  of  part  18  and  clause 
1 3.7  of  part  5  became  technically  equivalent  to  DISP 1 1 1 83.  The  DISP,  however,  is  a  more  rigorous  statement 
of  specifications.  Therefore,  it  has  been  the  stated  intent  of  the  NMSIG  to  directly  reference  the  ISP  1 1 183, 
Parts  1  through  3,  and  all  the  agreements  therein,  when  the  DISP  reaches  ISP  status.  Since  the  DISP  has  now 
progressed  to  ISP  11183  with  no  technical  changes,  the  NMSIG  Stable  management  communications 
agreements  in  clause  6  of  part  18  have  now  been  changed  to  point  directly  to  ISP  11183-1  through  -3 
[A0M1PT1,  A0M1PT2.  and  A0M1PT2]. 

(Refer  to  the  Working  Implementation  Agreements  Document  for  additional  status  information.) 
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4  Errata 

Editor's  Note:  [  "Defect  Report"  material  (including  applicability)  may  be  included  here.] 


The  following  table  indicates  the  clause,  type,  and  reference  document  of  technical  errata  to  this  part. 


Erratum 
No. 

Type  & 
Date 
Entered 

Referenced 
Document 

Clause 

Comment 

1 

Technical 
6/91 

NMSIG- 
91/08 

6.4.5 

This  clause,  previously  clause  6.2.6, 
was  modified  and  moved  to  clause 
6.4.5  to  clarify  that  it  is  intended  as  a 
support  agreement  for  CMIP  rather 
than  a  usage  agreement  for  CMIS. 

2 

Alignment 
9/91 

NMSIG- 
y  1  /  1  1  u 
NMSIG- 
91/113 

5 

This  clause  has  been  updated  to 
rciicci  aiigrirricrii  cnanycs  lu  inc 
relevant  base  standards  which  have 
just  progressed  to  IS  as  of  August, 
1991. 

3 

Technical 
9/91 

NMSIG- 
91/161 

6.2.2.2 

Move  text  from  clause  5.1.2.1  to 
more  appropriate  clause  6.2.2.2  and 
clarify  required  support  for  minimal 
filter  complexity  to  align  with  the  DISP 
11183. 

4 

Technical 
9/91 

NMSIG- 
91/161 

6.2.3 

Remove  unnecessary  restrictions  on 
sending  CMIP  time  parameters. 

5 

Alignnnent 
9/91 

NMSIG- 
91/114 

6.1.1 

Change  reference  to  required 
application  context  support  to  align 
with  IS  version  of  [SMO]. 

6 

Technical 
9/91 

NMSIG- 
91/161 

6.3.3.1 

Remove  clause  requiring  mandatory 
attribute  list  in  successful  set 
response  because  considered 
redundant  information. 
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Erratum 
No. 

Type  & 
Date 
Entered 

Referenced 
Document 

Clause 

Comment 

7 

Alignment 
9/91 

NMSIG- 
91/120 

7 

Update  clause  to  reflect  alignment 
changes  to  the  relevant  base 
standards  which  have  progressed  to 
IS  as  of  August,  1991. 

8 

Editorial 
9/91 

NMSIG- 
91/161 

6.3.6.1 

Move  clause  6.3.6.1  to  more 
appropriate  location  at  clause  7.1.5. 

9 

Alignment 
3/92 

NMSIG- 
92/066 

6.1.3 

Update  reference  because  number  of 
clause  in  other  part  of  OIW  Stable 
Agreements  changed. 

10 

Alignment 
6/92 

NMSIG- 
92/093 

5.2  -  5.7 

Update  text  to  reference  appropriate 
A0M2X  pDISPs  because  have 
equivalent  agreements,  but  are  more 
rigorous. 

11 

Alignment 
6/92 

NMSIG  - 
92/200 

6 

Update  text  to  reference  ISP  1 1 183 
which  is  technically  equivalent  with  lA 
text  but  is  more  rigorous. 

12 

Technical 
12/92 

NMSIG- 
92/409 

A.5.1.2 

Modify  package  name, 
transportConnectionRetransmissionlV 
MO-Package,  which  was  incorrectly 
specified  in  the  CHARACTERIZED  BY 
clause  of  the  MO  class  definition. 

13 

Technical 
12/92 

NMSIG- 
92/409 

A.5.1.2 

Modify  object  ID  in  REGISTERED  AS 
clause  of  the  MO  class  definition  to 
register  the  newly  modified  MO  (see 
erratum  12). 

14 

Technical 
12/92 

NMSIG- 
92/409 

B.3.1 

Modify  object  identifier  value  in 
TABLE  B.10  to  reflect  changes  in  MO 
definition  (see  errata  12  and  13). 

15 

Technical 
12/92 

NMSIG- 
92/409 

C.4.9 

Modify  object  identifier  value  in  the 
table  to  reflect  changes  in  MO 
definition  (see  errata  12  and  13). 
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5     Management  Functions  and  Services 


5.1       General  Agreements 


5.1.1        Conventions  Used  In  SMF  Agreements 

Each  System  Management  Function  defines  a  set  of  services  referred  to  in  this  document  as  "SMF  services." 
Agreements  pertinent  to  SMF  sen/ices  are  provided  in  the  following  subclauses.  Each  subclause  contains  a 
series  of  tables,  as  follows. 

For  each  SMF  service,  a  normative  table  references  text  agreements  which  constrain  the  usage  and/or  value 
of  the  associated  service  parameters.  Text  agreements  defined  elsewhere  in  this  document  are  referenced  by 
clause  number.  The  lack  of  a  row  or  reference  signifies  no  agreement  beyond  the  base  standard. 

These  tables  include  codes  which  specify  parameter  usage  for  request,  indication,  response,  and  confirmation 
service  primitives.  These  codes,  defined  in  subclause  1.8.3  of  these  agreements  (Classification  of 
Conformance) .  in  I  SO/I  EC  TR 1 0000-1  (Framework  and  Taxonomy  of  I  SPs)  [I  SPFRM] .  and  in  ISO/IEC  TP  8509 
(Service  Conventions)  [ISPSRVC],  are  repeated  here  for  reader  convenience: 


M  Mandatory 

0  Optional 

C(p)    If  Condition  p  exists,  then  paranneter  is  mandatory;  othen/vise,  the 

parameter  is  not  applicable. 
X  Excluded 

1  Out  Of  Scope 

In  these  agreements,  this  means  that,  for  the  corresponding  element, 

*  implementations  may  use  it  outside  the  scope  of  these  agreements, 

*  conformance  tests  shall  not  be  provided  for  it, 

*  implementations  may  conform  to  other  agreements  where  it  is  required, 

*  no  requirements  are  placed  on  either  transmitter  or  receiver  to  support 
it, 

*  receiver  actions  are  unspecified  when  present. 
Not  Applicable 

(=)  The  value  of  the  parameter  is  identical  to  the  corresponding  parameter  in 
the  interaction  described  by  the  preceding  related  service  primitive. 

U       The  use  of  the  parameter  is  a  service-user  option. 

P  The  parameter  is  mapped  directly  onto  the  corresponding  parameters  of 
the  CM  IS  service  primitive;  refer  to  subclause  6  for  agreements  regarding 
this  pass-through  parameter. 
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In  addition,  tlie  convention  ''A>  B"  is  used  in  norniative  tables  to  indicate  both  the  usage  specified  by  the  base 
standard  (A)  and  the  additional  constraint  imposed  by  these  agreements  (B).  This  convention  is  intended  to 
call  attention  to  agreements  which  modify  the  usage  of  a  service  parameter. 

Unless  othenA/ise  noted,  conditional  parameters  (C)  shall  be  present  according  to  the  conditions  defined  in 
[CMIS]  and  the  referenced  System  Management  Function  base  standard. 


5.1.2       General  Agreements  Referenced  By  Many  SMF  Services 

The  following  general  agreements  pertain  to  some  or  all  of  the  System  Management  Function  services  defined 
throughout  clause  5.  Normative  tables  for  each  SMF  service  reference  these  general  agreements  where 
applicable.  These  agreements  do  not  apply  to  SMF  services  and  parameters  which  do  not  reference  them. 


5.1.2.1        Maximum  Length  of  Notification  Identifier 

To  limit  implementation  complexity,  the  maximum  length  of  the  Notification  Identifier  parameter  shall  be  32  bits. 


5.1.2.2        Maximum  Number  of  SET  Items 

To  limit  Implementation  complexity,  the  maximum  number  of  SET  items  contained  within  specified  SMF  service 
parameters  that  recipients  must  be  able  to  process  shall  be  64. 


5.1.2.3        Maximum  Lengthi  of  Additional  Text 

To  limit  implementation  complexity,  the  maximum  length  of  the  Additional  Text  parameter  which  recipients 
must  be  able  to  process  shall  be  256  octets. 


5.1.2.4        Use  Of  Additional  Info 

Editor's  Note:  [The  Additional  Information  parameter,  described  in  [ARF]  clause  8.1.2.14,  includes  a 
"significance  indicator."  It  requires  that  "[e]ven  if  the  Additional  Information  parameter  is  not 
fully  understood,  an  event  report  indication  shall  be  issued  to  the  user.  Indication  that  the 
Additional  Information  parameter  is  not  fully  understood  is  a  local  matter."] 


13 


PART  18:  Network  Management 


December  1992  (Stable) 


5.2       Object  Management  Function  Agreements 


5.2.1       General  Agreements 

These  agreements  require  support  for  the  SMF  services  defined  by  the  object  management  standard  [OMFJ. 

These  agreements  also  require  conformance  to  the  abstract  syntaxes  identified  in  clause  1 1  of  the  object 
management  standard  [OMF]  and  specified  in  [DMI] ,  with  the  exception  of  event  record  subclasses.  If  support 
for  the  log  control  standard  [LCF]  as  described  in  clause  5.7  is  claimed,  then  all  [OMF]  event  record 
subclasses  shall  also  be  required  by  these  agreements.  These  agreements  permit  optional  negotiation  of  the 
system  management  functional  units  specified  in  clause  10  of  [OMF]. 


5.2.2       Specific  Agreements 

See  [ISP0M1]  for  specification  of  agreements  for  the  Object  Management  Function. 


5.3       State  Management  Function  Agreements 


5.3.1        General  Agreements 

These  agreements  require  support  for  the  SMF  services  defined  by  the  state  management  standard  [STMF]. 

These  agreements  also  require  conformance  to  the  abstract  syntaxes  identified  in  clause  1 1  of  the  state 
management  standard  [STMF]  and  specified  in  [DMI],  with  the  exception  of  event  record  subclass.  If  support 
for  the  log  control  standard  [LCF]  as  described  in  clause  5.7  is  claimed,  then  all  [STMF]  event  record 
subclasses  shall  also  be  required  by  these  agreements.  These  agreements  permit  optional  negotiation  of  the 
State  Change  Reporting  functional  unit  specified  in  clause  10  of  [STMF]. 


5.3.2       Specific  Agreements 

See  [ISPSTM2]  for  specification  of  agreements  for  the  State  Management  Function. 
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5.4 


Attributes  For  Representing  Relationships  Agreements 


5.4.1 


General  Agreements 


These  agreements  require  support  for  the  SMF  services  defined  by  the  Attributes  For  Representing 
Relationships  standard  [ARR]. 

These  agreements  also  require  conformance  to  the  abstract  syntaxes  identified  in  clause  1 1  of  the  attributes 
for  representing  relationships  standard  [ARR]  and  specified  in  [DMI],  with  the  exception  of  event  record 
subclass.  If  support  for  the  log  control  standard  [LCF]  as  described  in  clause  5.7  is  claimed,  then  all  [ARR] 
event  record  subclasses  shall  also  be  required  by  these  agreements.  These  agreements  permit  optional 
negotiation  of  the  Relationship  Change  Reporting  functional  unit  specified  in  clause  10  of  [ARR]. 


5.4.2       Specific  Agreements 

See  [ISPARR3]  for  specification  of  agreements  for  Attributes  for  Representing  Relationships. 


5.5       Alarm  Reporting  Function  Agreements 


5.5.1        General  Agreements 

These  agreements  require  support  for  the  SMF  services  defined  by  the  alarm  reporting  standard  [ARF]. 

These  agreements  also  require  conformance  to  the  abstract  syntaxes  identified  in  clause  1 1  of  the  alarm 
reporting  standard  [ARF]  and  specified  in  [DMI],  with  the  exception  of  event  record  subclass.  If  support  for 
the  log  control  standard  [LCF]  as  described  in  clause  5.7  is  claimed,  then  all  [ARF]  event  record  subclasses 
shall  also  be  required  by  these  agreements.  These  agreements  permit  optional  negotiation  of  the  Alarm 
Reporting  functional  unit  specified  in  clause  10  of  [ARF]. 


5.5.2       Specific  Agreements 

See  [ISPAR4]  for  specification  of  agreements  for  the  Alarm  Reporting  Function. 
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5.6 


Event  Report  Management  Function  Agreements 


5.6.1  General  Agreements 

These  agreements  require  support  for  the  SMF  services  defined  by  the  event  report  management  standard 
[ERMF]. 

These  agreements  also  require  conformance  to  the  abstract  syntaxes  identified  in  clause  1 1  of  the  event  report 
management  standard  [ERMF]  and  specified  in  [DM!].  These  agreements  permit  optional  negotiation  of  the 
Monitor  Event  Report  Management  and  Event  Report  Management  functional  units  specified  in  clause  10  of 
[ERMF]. 

5.6.2  Specific  Agreements 

See  [ISPERM5]  for  specification  of  agreements  for  the  Event  Report  Management  Function. 


5.7       Log  Control  Function  Agreements 
5.7.1       General  Agreemehtis 

These  agreements  require  the  SMF  services  defined  by  the  log  control  standard  [LCF]. 

These  agreements  also  require  conformance  to  the  abstract  syntaxes  identified  in  clause  1 1  of  the  log  control 

standard  [LCF]  and  specified  in  [DM1]. 

If  any  other  function  defined  in  clause  5  that  supports  notifications  is  supported,  then  any  event  record  subclass 
defined  by  that  function  is  required  for  the  log  control  function. 

These  agreements  permit  optional  negotiation  for  log  control  and  monitor  log  control  functional  units  specified 

in  section  10  of  [LCF|.  ■ 

The  appropriate  CMIS  error  (i.e.,  invalidAttributeValue)  shall  be  returned  for  any  attempt  to  set  Max  log  size  less 
than  the  value  of  Current  log  size,  except  if  setting  the  Max  log  size  to  zero.  When  the  Max  log  size  is  set  to 
zero,  then  the  maximum  log  size  is  unlimited. 
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5.7.2       Specific  Agreements 

See  [ISPLC6]  for  specification  of  agreements  for  the  Log  Control  Function. 
5.8       Security  Alarm  Reporting  Function  Agreements 
5.8.1        General  Agreements 

These  agreements  require  support  for  the  SMF  services  defined  by  the  security  alarm  reporting  standard 
[SARF]. 

These  agreements  also  require  conformance  to  the  abstract  syntaxes  identified  in  clause  11  of  the  alarm 
reporting  standard  [SARF]  and  specified  in  [DMI],  with  the  exception  of  event  record  subclass.  If  support  for 
the  log  control  standard  [LCF]  as  described  in  clause  5.7  is  claimed,  then  all  [SARF]  event  record  subclasses 
shall  also  be  required  by  these  agreements.  These  agreements  permit  optional  negotiation  of  the  security 
alarm  reporting  function  as  specified  in  section  10  of  [SARF]. 


5.8.2       Security  Alarm  Reporting 

This  subclause  provides  agreements  pertinent  to  the  Security  Alarm  Reporting  SMF  service  defined  by  section 
9.2  of  [SARF].  Subclause  6  provides  agreements  pertinent  to  CMIS  services  and  pass-through  parameters 
used  by  this  SMF  service. 


Table  1  -  Agreements  on  parameter  usage  pertinent  to  the  Security  Alarm  Reporting  SMF  service 


SMF  Security  Alarm  Reporting 
parameter 

Req 

Rsp 

SMF  agreements 

Event  Type 

M 

C{=) 

Event  Information 

Security  Alarm  Cause 

M 

Security  Alarm  Severity 

M 

Security  Alarm  Detector 

M 

[1] 

Service  User 

M 

Service  Provider 

M 

Notification  Identifier 

U 

5.1.2.1 
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SMF  Security  Alarm  Reporting 
parameter 

Req 

Rsp 

SMF  agreements 

Correlated  Notifications 

U 

5.1.2.2 

Additional  Text 

U 

5.1.2.3 

Additional  Info 

u 

5.1.2.2,  5.1.2.4 

[1]  To  avoid  ambiguity,  the  Distinguished  Name  form  of  this  parameter  shall  be  implemented  and 
may  be  used.  Use  of  Local  Distinguished  Name  and  Non-Specific  forms  are  beyond  the  scope 
of  these  agreements.  If  an  implementation  is  unable  to  decode  or  understand  the  semantics 
of  this  parameter,  an  appropriate  CMIS  error  (i.e..  Invalid  Attribute  Value)  shall  be  returned. 


5.9       Security  Audit  Trail  Function  Agreements 


5.9.1        General  Agreements 

These  agreements  require  support  for  the  SMF  services  defined  by  the  security  audit  trail  standard  [SATF]. 

These  agreements  also  require  conformance  to  the  abstract  syntaxes  identified  in  clause  11 .2  of  the  security 
audit  trail  standard  [SATF]  and  specified  in  [DMI],  with  the  exception  of  event  log  record  subclass.  If  support 
for  the  log  control  standard  [LCF]  as  described  in  clause  5.7  is  claimed,  then  all  [SATF]  event  log  record 
subclasses  shall  also  be  required  by  these  agreements. 


5.9.2       Security  Audit  Trail  Reporting  SMF  Service 

This  subclause  provides  agreements  pertinent  to  the  Security  Audit  Trail  Reporting  SMF  service  defined  by 
section  9.2  of  [SATF] .  Clause  6  provides  agreements  pertinent  to  CMIS  services  and  pass-through  parameters 
used  by  this  SMF  service. 

Table  2  -  Agreements  on  parameter  usage  pertinent  to  the  Security  Audit  Trail  Reporting  SMF 

service 


SMF  Security  Audit  Trail  parameter 

Req 

Rsp 

SMF  agreements 

Event  Type 

M 

C(=) 

5.9.2.1 

Event  Information 

Service  Report  Cause 

C(1) 
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SMF  Security  Audit  Trail  parameter 

Req 

Rsp 

SMF  agreements 

Notification  Identifier 

U 

5.1.2.3 

Correlated  Notifications 

u 

5.1.2.4 

Additional  Text 

u 

5.1.2.5 

Additional  Info 

U>l 

5.1.2.6 

C(1):  Manadatory  (M)  for  serviceReport 
5.9.2.1  Notifications 

These  Implementors'  Agreements  require  support  for  both  the  seviceReport  and  usageReport  notification 
types. 

5.9.3       Security  Audit  Trail  Record 

This  subclause  is  a  placeholder  for  agreements  pertaining  to  the  Security  Audit  Trail  Record  (SATR)  managed 
object  class. 

5.10  Objects  and  Attributes  for  Access  Control  Agreements 

(Refer  to  the  Working  Implementation  Agreements  Document.) 

5.11  Accounting  Meter  Function  Agreements 

(Refer  to  the  Working  Implementation  Agreements  Document.) 

5.12  Workload  Monitoring  Function  Agreements 

(Refer  to  the  Working  Implementation  Agreements  Document.) 
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5.13  Summarization  Function  Agreements 

(Refer  to  the  Working  Implementation  Agreements  Document.) 

5.14  Test  Management  Function  Agreements 

(Refer  to  the  Working  Implementation  Agreements  Document.) 

5.15  Confidence  and  Diagnostic  Test  Classes  Agreements 

(Refer  to  the  Working  Implementation  Agreements  Document.) 

6     Management  Comnnunications 

This  clause  covers  the  agreements  pertaining  to  the  use  of  associations  over  which  to  conduct  management 
communications,  and  agreements  for  management  communication,  itself,  by  reference  to  ISP  11183 
[A0M1PT1,  A0M1PT2,  and  A0M1PT3].  ISP  11183  defines  two  profiles.  A0M11  (Basic  Management 
Communications)  [A0M1PT3]  and  A0M12  (Enhanced  Management  Communications)  [A0M1PT2],  and 
defines  upper  layer  requirements  [AOMI PTI]  for  each  of  these  profiles. 

For  rigorous  specification  of  the  agreements  relevant  to  clause  6.  Management  Communications,  see  ISP 
1 1 183  [AOMI  PT1 .  AOMI  PT2,  and  AOMI  PT3]. 

6.1        Association  Policies 

Associations  are  established  using  the  procedures  described  in  [ACSEP]. 

6.1.1  Application  Context  Negotiation 

These  I  As  specify  the  negotiation  of  the  Systems  management  application  context  specified  in  [SMO].  Other 
application  contexts  are  outside  the  scope  of  these  agreements. 

6.1.2  Functional  Unit  Negotiation 

These  lAs  specify  that  System  Management  Functional  Units  are  negotiated  as  specified  in  [SMO]. 
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6.1.3       Security  Aspects  of  Associations 

The  ACSE  authentication  mechanisms  and  associated  data  types  shall  be  as  defined  in  clause  9  (Upper  Layers 
Security)  of  part  12  of  the  01 W  Working  Agreements. 

Support  of  ACSE  authentication  is  optional. 


7    Management  Information 

This  clause,  which  is  based  on  ISO  standards'  documents  [MIM]  and  [GDMO],  containsagreements  regarding 
basic  concepts  and  modelling  techniques  related  to  management  information.  It  enumerates  agreements  on 
(i)  the  information  model  (subclause  7.1)  and  (ii)  guidelines  for  defining  management  information  (subclause 
7.2).  These  agreements  apply  to  developers  of  contributions  to  the  Management  Information  Library  (MIL). 
They  form  a  normative  part  of  the  standard;  hence  they  must  be  strictly  followed  while  defining  management 
information.  It  is  not  within  the  scope  of  this  clause  to  make  agreements  about  specific  elements  of 
management  information  or  to  define  such  specific  elements  of  management  information.  Such  definitions 
and/or  agreements  can  be  obtained  via  the  Management  Information  Library. 


7.1       The  Information  Model 

When  modelling  management  information,  these  agreements  require  use  of  [MIM]  with  the  following  additional 
constraints. 


7.1.1  Inheritance 

The  following  constraint  related  to  inheritance  is  enforced  in  order  to  remove  potential  ambiguities: 

During  the  lifetime  of  a  managed  object  instance,  each  of  its  attributes  must  have  a  value  that  is 
valid  for  the  attribute  syntax  of  that  attribute. 


7.1.2  Interoperability 


7.1.2.1         Interoperability  Provided  By  The  Agent  System 

Allomorphism,  as  specified  in  clause  5.2.3.1  of  [MIM],  is  out  of  scope.  Any  other  specification  within  the  [MIM] 
or  [GDMO]  that  refers  to  allomorphism  is  also  out  of  scope. 


21 


PART  18:  Network  Management 


December  1992  (Stable) 


7.1.2.2        Interoperability  Provided  By  The  Manager  System 

The  semantics  of  clause  5.2.3.2  of  [MIM]  are  supported.  A  manager  system  can  supply  the  object  identifier 
as  specified  in  clause  7.4.5  of  [GDMO]  to  specify  that  a  managed  object  should  perform  an  operation  as  a 
member  of  its  actual  class.  The  object  identifier  is  intended  to  be  used  in  requests  only,  and  shall  be 
interpreted  by  the  responder  as  a  requirement  to  return  its  real  object  class  value  in  the  response.  Agent 
systems  shall  support  this  object  identifier  as  defined  in  [MIM]  5.2.3.2  and  [GDMO]  7.4.5. 


7.1.3  Filter 

The  concept  of  filter  is  supported  as  specified  in  clause  6. 
6.2.2.2  of  these  agreements. 

7.1.4  Management  Operations 


Restrictions  on  its  usage  are  specified  in  subclause 


An  implementation  that  complies  with  these  agreements  shall  support  management  operations  as  defined  in 
clause  5.3.4  of  [MIM]  with  the  following  additional  clarification. 

[MIM]  clause  5.3.4.1  (2).  [DMI]  clause  6.14,  and  [GDMO]  clause  6.1.4  imply  that  the  object  class 
attribute  shall  not  be  included  in  the  create  request  Attribute  List  parameter.  [MIM]  states  that  any 
conflicting  duplicate  specifications  cause  the  request  to  fail. 


7.1.5       Deletion  of  Objects  Containing  Objects 

The  error  'Processing  Failure'  shall  be  returned  if  a  managed  object  has  existing  contained  objects  and  the 
behavior  defined  for  that  object  prohibits  its  deletion  unless  all  contained  objects  have  been  deleted. 


7.2       Guidelines  for  the  Definition  of  Management  Information 

This  subclause  contains  agreements  about  guidelines  for  the  definition  of  management  information,  as 
specified  in  [GDMO]. 


7.2.1        Syntactical  Definitions  of  Management  Information 


7.2.1.1        Attribute  Template 

The  following  constraint  applies  to  the  Attribute  Template  specified  in  clause  9.7.2  of  [GDMO]: 
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The  BEHAVIOUR  construct  may  be  omitted  only  If  a  behaviour  definition  has  been  inherited  from 
the  parent  attribute,  i.e.,  the  attribute  is  derived  from  another  attribute  whose  definition  contains  a 
BEHAVIOUR  construct. 


7.2.2       Guidelines  For  Defining  Behaviour 

The  following  details  should  be  provided  in  the  set  of  specifications  defining  a  managed  object  class: 

a)  a  textual  description  of  the  network/system  resource(s)  the  managed  object  class  represents, 
including  their  functional  role; 

b)  a  description  of  the  relationships  that  can  occur  between  different  instances  of  the  managed 
object  class  being  defined,  as  well  as  those  that  can  occur  between  instances  of  the  managed 
object  class  being  defined  and  instances  of  other  managed  object  classes; 

c)  a  description  of  the  operations  that  are  supported  by  the  managed  object  class,  with  precise 
definition  of  the  effects,  side  effects  if  any,  constraints,  response  notifications,  failure  modes; 

d)  specification  of  how  instances  of  this  managed  object  class  are  created  and  deleted,  particularly 
whether  they  can  be  created/deleted  via  the  management  CREATE/DELETE  operations; 

e)  a  description  of  notifications  that  can  be  generated,  the  conditions  that  generate  them  (e.g., 
crossing  of  a  threshold),  their  contents  and  side-effects,  if  any.  In  particular,  identify  all  the 
attributes  that  are  subject  to  the  AttributeChange  and  StateChange  notifications,  if  these 
notifications  are  supported; 

f)  other  constraints,  including  those  involving  other  managed  object  classes. 


7.2.3       Other  Guidelines 

The  Systems  Management  functions  have  defined  various  attributes  and  events,  as  indicated  in  clause  5  of 
these  agreements.  Object  definers  should  mal<e  use  of  these  attributes  and  events  wherever  applicable. 
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8  Conformance 


8.1  Introduction 

Clause  8  specifies  the  conformance  requirements  for  tine  OIW  Networl<  Management  Implementation 
Agreements  (I  As).  Implementorsof  products  will  provide  claims  of  conformance  tothese  requirements.  These 
claims  will  be  in  the  form  of  Protocol  Implementation  Conformance  Statements  (PICS)  and  Managed  Object 
Conformance  Statements  (MOCS).  These  requirements  will  also  be  used  to  develop  test  cases  which  will  be 
used  to  validate  claims  of  conformance.  This  clause  defines  the  general  conformance  requirements  and 
criteria  which  shall  be  used  as  a  basis  for  tests  of  implementations  claiming  conformance  to  these  agreements. 
Dependent  conformance  requirements  are  defined  in  the  context  in  which  they  are  used  (e.g.,  SMF  general 
conformance  requirements  include  CMIP  dependent  conformance  requirements  for  CMIS  services  used). 

Editor's  Note:  [The  use  of  the  two  terms,  "general  conformance  class"  and  "dependent  conformance 
class",  is  under  review.  When  a  final  answer  to  Question  Q1  /49.9  (on  the  long  term  solution 
to  general  and  dependent  conformance)  has  been  approved,  it  is  intended  to  clarify  and/or 
correct  this  conformance  section.] 

(Refer  to  the  Working  Implementation  Agreements  Document  for  additional  introductory  text.) 


8.2       General  Requirements  of  Conformance 

Conformance  for  these  agreements  is  designed  to  specify  a  well-defined  set  of  management  capabilities  and 
features.  For  the  purposes  of  organization  and  clarity  of  these  agreements,  management  has  been  divided 
into  three  categories.  Clauses  5  (Management  Functions  and  Services),  6  (Management  Communications) 
and  7  (Management  Information)  state  the  agreements  which  respectively  comprise  three  conformance 
categories.  Within  these  categories,  particular  conformance  categories  are  specified  which  delineate 
conformance  requirements  for  a  well-defined  and  bounded  set  of  management  capabilities  and  features  (e.g., 
within  the  Management  Functions  and  Services  conformance  categories,  a  conformance  category  is  specified 
which  defines  conformance  to  Alarm  Reporting  and  State  Management  Services).  Once  a  conformance 
category  is  delineated  which  specifies  the  set  of  requirements  for  that  category,  tests  can  be  developed  to 
evaluate  conformance  of  products  to  that  conformance  category.  And  finally,  for  some  conformance 
categories,  roles  (Manager,  Agent,  or  both)  are  specified.  One  or  more  roles  may  be  supported  for  those 
conformance  categories  to  which  an  implementation  is  conformant. 

The  development  of  conformance  categories  will  enable: 

a)  users  to  define  procurement  specifications; 

b)  vendors  to  define  management  capabilities  and  features; 

c)  conformance  test  houses  and  others  to  define  test  cases. 
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To  be  conformant  to  the  lAs,  an  implementation  sfiall  be  conformant  to  at  least  one  of  the  following  categories: 

a)  Management  Communication; 

b)  Management  Functions  and  Services; 

c)  Management  Information. 

Implementations  which  are  conformant  to  these  categories  shall  comply  with  the  requirements  stated  in  the 
following  clause. 


8.3       Specific  Conformance  Categories 


8.3.1        IVIanagement  Communication  Categories 

To  be  conformant  to  the  Management  Communication  categories,  an  implementation  shall  conform  to 
agreements  in  clause  6.  Conformance  to  management  communication  also  requires  an  implementor  to  state 
which  of  the  management  communication  profiles  specified  in  clause  6  are  supported  in  the  implementation. 
The  implementor's  statement  of  which  profile  is  supported  shall  be  indicated  in  a  CMIP  PICS  as  follows.  The 
implementor  shall  complete  the  PICS  proforma  as  specified  by  one  of  the  profiles  specified  in  clause  6. 

Note:   [Conformance  requirements  for  these  lAs,  relating  to  services  required  of  the  upper  layers  and 
other  ASEs,  are  discussed  in  part  5,  clause  13.7] 


8.3.2       Management  Functions  and  Services  Conformance  Categories 

To  be  conformant  to  the  Management  Functions  and  Services  categories,  an  implementation  shall  conform 
to  the  agreements  in  clause  5  on  at  least  one  of  the  categories  defined  below  in  either  a  manager  role,  an  agent 
role  or  both  roles.  [Note:  These  categories  are  aligned  with  the  proposed  A0M2x  Profiles  for  Systems 
Management  Functions.]  [NMSIGl]  Conformance  to  agreements  in  clause  5  requires  conformance  to 
referenced  ISO  standards/CCITT  Recommendations  and  to  all  other  clauses  referenced  in  5,  including 
dependent  conformance  to  the  underlying  services  required  by  the  SMFs. 

The  implementor  shall  state  which  of  the  following  conformance  categories  are  supported.  For  each  category, 
the  implementor  shall  complete  the  related  PICS  and  MOCS  proformas  to  indicate  which  functional  unit(s)  and 
role(s)  are  supported. 


8.3.2.1  General  Management  Capabilities  Conformance  Category 
Note:    [This  category  corresponds  to  proposed  profile  A0M211  [A0M211].] 
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Conformance  to  the  General  Management  Capabilities  Conformance  Category  requires  general  conformance 
to  the  Object  Management  Function  [OMF],  general  conformance  to  the  State  Management  Function  [STMF], 
general  conformance  to  the  Attributes  for  Representing  Relationships  Function  [ARR],  and  general 
conformance  to  the  Alarm  Reporting  Function  [ARF].  To  be  conformant  to  the  Object  Management  Function, 
an  implementation  shall  conform  to  the  requirements  stated  in  [OMF].  In  addition,  an  implementation  shall 
conform  to  clause  5.2  of  these  agreements  and  all  other  clauses  referenced  in  5.2.  To  be  conformant  to  the 
State  Management  Function,  an  implementation  shall  conform  to  the  requirements  stated  in  [STMF].  In 
addition,  an  implementation  shall  conform  to  clause  5.3  of  these  agreements  and  all  other  clauses  referenced 
in  5.3.  To  be  conformant  with  the  Attributes  for  Representing  Relationships  Function,  an  implementation  shall 
conform  to  the  requirements  stated  in  [ARR],  In  addition,  an  implementation  shall  conform  to  clause  5.4  of 
these  agreements  and  all  other  clauses  referenced  in  5.4.  To  be  conformant  to  the  Alarm  Reporting  Function, 
an  implementation  shall  conform  to  the  requirements  stated  in  [ARF].  In  addition,  an  implementation  shall 
conform  to  clause  5.5  of  these  agreements  and  all  clauses  referenced  in  5.5. 


8.3.2.2  Alarm  Reporting  and  State  Management  Capabilities  Conformance  Category 
Note:    [This  category  corresponds  to  proposed  profile  AOM212  [AOM212].] 

Conformance  to  the  Alarm  Reporting  and  State  Management  Capabilities  Conformance  Category  requires 
general  conformance  to  the  State  Management  Function  [STMF],  general  conformance  to  the  Alarm  Reporting 
Function  [ARF],  and  dependent  conformance  to  the  Object  Management  Function  [OMF].  To  be  conformant 
to  the  State  Management  Function,  an  implementation  shall  conform  to  the  requirements  stated  in  [STMF]. 
In  addition,  an  implementation  shall  conform  to  clause  5.3  of  these  agreements  and  all  other  clauses 
referenced  in  5.3.  To  be  conformant  to  the  Alarm  Reporting  Function,  an  implementation  shall  conform  to  the 
requirements  stated  in  [ARF].  In  addition,  an  implementation  shall  conform  to  clause  5.5  of  these  agreements 
and  all  clauses  referenced  in  5.5. 

Dependent  conformance  to  the  Object  Management  Function  required  by  the  Alarm  Reporting  and  State 
Management  Capabilities  Conformance  Category  requires  support  for  the  PT-SET  and  PT-GET  elements  of 
procedure  in  clauses  1 1 .1 .6  and  1 1 .1 .7  of  [OMF]  in  either  the  agent  role,  the  manager  role,  or  both  roles  as 
specified  by  the  implementor  in  the  PICS.  In  addition,  an  implementation  shall  conform  to  clause  5.2.7  and 
clause  5.2.9  of  these  agreements  and  all  clauses  referenced  in  5.2.7  and  5.2.9.  The  implementation  need  only 
support  the  PT-SET  and  PT-GET  elements  of  procedure  as  applied  to  the  State  Management  Attributes 
identified  in  [STMF]  and  specified  in  [DMI].  An  implementation  shall  also  conform  to  the  notifications  identified 
in  [STMF]  and  specified  in  [DMI]. 

For  each  role  claimed  to  be  supported  in  the  PICS,  an  implementation  shall  support  the  transfer  syntax  derived 
from  the  encoding  rules  defined  in  [BER]  named  [joint-iso-ccitt  asn1(1)  basic  encoding(l)],  for  the  purpose 
of  generating  and  interpreting  the  MAPDUs  required  to  support  that  portion  of  the  "CMIP-PCI"  abstract  syntax 
defined  in  [CMIP]  required  to  support  the  PT-GET  and  PT-SET  elements  of  procedure  as  defined  in  clauses 
11.1.6  and  11.1.7  of  [OMF]. 

The  implementation  shall  support  the  transfer  syntax  derived  from  the  encoding  rules  specified  in  [BER]  named 
[joint-iso-ccitt  asnl  (1 )  basic  encoding(1 )],  for  the  purpose  of  generating  and  interpreting  the  MAPDUs  defined 
by  the  abstract  data  types  referenced  in  1 1 .2.6  of  [STMF]. 
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8.3.2.3        Alarm  Reporting  Capabilities  Conformance  Category 
Note:   [This  category  corresponds  to  proposed  profile  AOM213  [AOM213].] 

Conformance  to  the  Alarm  Reporting  Capabilities  Conformance  Category  requires  general  conformance  to  the 
Alarm  Reporting  Function  [ARF].  To  be  conformant  to  the  Alarm  Reporting  Function,  an  implementation  shall 
conform  to  the  requirements  stated  in  [ARF].  In  addition,  an  implementation  shall  conform  to  clause  5.5  of 
these  agreements  and  all  clauses  referenced  in  5.5. 


8.3.2.4        General  Event  Report  Management  Conformance  Category 
Note:    [This  category  corresponds  to  proposed  profile  AOM221  [AOM221].] 

Conformance  to  the  General  Event  Report  Management  Conformance  Category  requires  general  conformance 
to  the  Event  Report  Management  Function  [ERMF],  dependent  conformance  to  the  Object  Management 
Function  [OMF],  and  dependent  conformance  to  the  State  Management  Function  [STMF].  To  be  conformant 
to  the  Event  Report  Management  Function,  an  implementation  shall  conform  to  the  requirements  stated  in 
[ERMF].  In  addition,  an  implementation  shall  conform  to  clause  5.6  of  these  agreements  and  all  clauses 
referenced  in  5.6. 

Dependent  conformance  to  the  Object  Management  Function  required  by  the  General  Event  Report 
Management  Conformance  Category  requires  support  for  the  PT-SET,  PT-GET,  PT-CREATE,  PT-DELETE, 
object  creation  reporting,  object  deletion  reporting,  and  attribute  value  change  reporting  elements  of  procedure 
in  clauses  11.1.1  through  11.1.7  of  [OMF]  in  either  the  agent  role,  the  manager  role,  or  both  roles  as  specified 
by  the  implementor  in  the  PICS.  In  addition,  an  implementation  shall  conform  to  clause  5.2.2  through  clause 
5.2.7,  and  clause  5.2.9  of  these  agreements  and  all  clauses  referenced  in  these  clauses.  An  implementation 
shall  also  conform  to  the  notifications  identified  in  [OMF]  and  specified  in  [DMI]. 

Dependent  conformance  to  the  State  Management  Function  required  by  the  General  Event  Report 
Management  Conformance  Category  requires  support  for  the  state  change  reporting  elements  of  procedure 
in  clause  11.1  of  [STMF]  in  either  the  agent  role,  the  manager  role,  or  both  roles  as  specified  by  the 
implementor  in  the  PICS.  In  addition,  an  implementation  shall  conform  to  clause  5.3.2  of  these  agreements 
and  all  clauses  referenced  by  clause  5.3.2.  An  implementation  shall  also  conform  to  the  notifications  identified 
in  [STMF]  and  specified  in  [DMI]. 

For  each  role  claimed  to  be  supported  in  the  PICS,  an  implementation  shall  support  the  transfer  syntax  derived 
from  the  encoding  rules  defined  in  [BER]  named  [joint-iso-ccitt  asn1(1)  basic  encoding(l)],  for  the  purpose 
of  generating  and  interpreting  the  MAPDUs  required  to  support  that  portion  of  the  "CMIP-PCI"  abstract  syntax 
defined  in  [CMIP]  required  to  support  the  PT-SET,  PT-GET,  PT-CREATE,  PT-DELETE,  object  creation  reporting, 
object  deletion  reporting,  and  attribute  value  change  reporting  elements  of  procedure  as  defined  in  clauses 
11.1.1  through  11.1.7  of  [OMF]. 

The  implementation  shall  support  the  transfer  syntax  derived  from  the  encoding  rules  specified  in  [BER]  named 
[joint-iso-ccitt  asn  1(1)  basic  encoding(l)],  forthe  purpose  of  generating  and  interpreting  the  MAPDUs  defined 
by  the  abstract  data  types  referenced  in  1 1.2.5  of  [OMF]. 


27 


PART  18:  Network  Management 


December  1992  (Stable) 


For  each  role  claimed  to  be  supported  in  the  PICS,  an  implementation  shall  support  the  transfer  syntax  derived 
from  the  encoding  rules  defined  in  [BER]  named  [joint-iso-ccitt  asn1  (1)  basic  encodlng(1)],  for  the  purpose 
of  generating  and  interpreting  the  MAPDUs  required  to  support  that  portion  of  the  "CMIP-PCI"  abstract  syntax 
defined  in  [CMIP]  required  to  support  the  state  change  reporting  elements  of  procedure  as  defined  in  clause 
11.1  of  [STMF]. 

The  implementation  shall  support  the  transfer  syntax  derived  from  the  encoding  rules  specified  in  [BER]  named 
[joint-iso-ccitt  asnl  (1)  basic  encoding(l)],  for  the  purpose  of  generating  and  interpreting  the  MAPDUs  defined 
by  the  abstract  data  types  referenced  in  1 1 .2.6  of  [STIVIF]. 


8.3.2.5        General  Log  Control  Conformance  Category 

Note:    [This  category  corresponds  to  proposed  profile  AOM231  [AOM231].] 

Conformance  to  the  Log  Control  Conformance  Category  requires  general  conformance  to  the  Log  Control 
Function  [LCF],  dependent  conformance  to  theObject  Management  Function  [OMF],  dependent  conformance 
to  the  State  Management  Function  [STMF]  and  dependent  conformance  to  the  Alarm  Reporting  Function 
[ARF].  To  be  conformant  to  the  Log  Control  Function,  an  implementation  shall  conform  to  the  requirements 
stated  in  [LCF] .  In  addition,  an  implementation  shall  conform  to  clause  5.7  of  these  agreements  and  all  clauses 
referenced  in  5.7. 

Dependent  conformance  to  the  Object  Management  Function  required  by  the  General  Log  Control 
Conformance  Category  requires  support  for  the  PT-SET,  PT-GET,  PT-CREATE,  PT-DELETE,  object  creation 
reporting,  object  deletion  reporting,  and  attribute  value  change  reporting  elements  of  procedure  In  clauses 
11.1.1  through  11.1.7  of  [OMF]  in  either  the  agent  role,  the  manager  role,  or  both  roles  as  specified  by  the 
implementor  in  the  PICS.  In  addition,  an  implementation  shall  conform  to  clause  5.2.2  through  clause  5.2.7, 
and  clause  5.2.9  of  these  agreements  and  all  clauses  referenced  in  these  clauses.  An  implementation  shall  also 
conform  to  the  notifications  identified  in  [OMF]  and  specified  in  [DMI]. 

Dependent  conformance  to  the  State  Management  Function  required  by  the  General  Log  Control  Conformance 
Category  requires  support  for  the  state  change  reporting  elements  of  procedure  in  clause  11.1  of  [STMF]  in 
either  the  agent  role,  the  manager  role,  or  both  roles  as  specified  by  the  implementor  in  the  PICS.  In  addition, 
an  implementation  shall  conform  to  clause  5.3.2  of  these  agreements  and  all  clauses  referenced  by  clause 
5.3.2.  An  implementation  shall  also  conform  to  the  notifications  identified  in  [STMF]  and  specified  in  [DMI]. 

Dependent  conformance  to  the  Alarm  Reporting  Function  required  by  the  General  Log  Control  Conformance 
Category  requires  support  for  the  alarm  reporting  elements  of  procedure  in  clause  1 1 . 1  of  [ARF]  in  either  the 
agent  role,  the  manager  role,  or  both  roles  as  specified  by  the  implementor  in  the  PICS.  In  addition,  an 
implementation  shall  conform  to  clause  5.5.2  of  these  agreements  and  all  clauses  referenced  by  clause  5.5.2. 
An  implementation  shall  also  conform  to  the  notifications  identified  in  [ARF]  and  specified  in  [DMI]. 

For  each  role  claimed  to  be  supported  in  the  PICS,  an  implementation  shall  support  the  transfer  syntax  derived 
from  the  encoding  rules  defined  in  [BER]  named  [joint-iso-ccitt  asn1(1)  basic  encoding(l)],  for  the  purpose 
of  generating  and  interpreting  the  MAPDUs  required  to  support  that  portion  of  the  "CMIP-PCI"  abstract  syntax 
defined  in  [CMIP]  required  to  support  the  PT-SET,  PT-GET,  PT-CREATE,  PT-DELETE,  object  creation  reporting. 
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object  deletion  reporting,  and  attribute  value  change  reporting  elements  of  procedure  as  defined  in  clauses 
11.1.1  through  11.1.7  of  [OMF]. 

The  implementation  shall  support  the  transfer  syntax  derived  from  the  encoding  rules  specified  in  [BER]  named 
[joint-iso-ccitt  asnl  (1 )  basic  encoding(1 )],  for  the  purpose  of  generating  and  interpreting  the  MAPDUs  defined 
by  the  abstract  data  types  referenced  in  1 1 .2.5  of  [OMF]. 

For  each  role  claimed  to  be  supported  in  the  PICS,  an  implementation  shall  support  the  transfer  syntax  derived 
from  the  encoding  rules  defined  in  [BER]  named  [joint-iso-ccitt  asn1(1)  basic  encoding(l)],  for  the  purpose 
of  generating  and  interpreting  the  MAPDUs  required  to  support  that  portion  of  the  "CMIP-PCI"  abstract  syntax 
defined  in  [CMIP]  required  to  support  the  state  change  reporting  elements  of  procedure  as  defined  in  clause 
11.1  of  [STMF]. 

The  implementation  shall  support  the  transfer  syntax  derived  from  the  encoding  rules  specified  in  [BER]  named 
[joint-iso-ccitt  asn1  (1 )  basic  encoding(1 )],  for  the  purpose  of  generating  and  interpreting  the  MAPDUs  defined 
by  the  abstract  data  types  referenced  in  1 1 .2.6  of  [STMF]. 

For  each  role  claimed  to  be  supported  in  the  PICS,  an  implementation  shall  support  the  transfer  syntax  derived 
from  the  encoding  rules  defined  in  [BER]  named  [joint-iso-ccitt  asnl  (1)  basic  encoding(l)],  for  the  purpose 
of  generating  and  interpreting  the  MAPDUs  required  to  support  that  portion  of  the  "CMIP-PCI"  abstract  syntax 
defined  in  [CMIP]  required  to  support  the  alarm  reporting  elements  of  procedure  as  defined  in  clause  11.1  of 
[ARF]. 

The  implementation  shall  support  the  transfer  syntax  derived  from  the  encoding  rules  specified  in  [BER]  named 
[joint-iso-ccitt  asnl  (1 )  basic  encoding(1 )],  for  the  purpose  of  generating  and  interpreting  the  MAPDUs  defined 
by  the  abstract  data  types  referenced  in  1 1 .2.5  of  [ARF]. 


8.3.3       Management  Information  Conformance  Category 

To  be  conformant  to  the  Management  Information  Conformance  Category,  an  implementation  shall  include 
at  least  one  managed  object  defined  as  specified  by  clause  7.  The  requirements  for  managing  this  managed 
object  shall  not  conflict  with  the  specifications  in  clauses  5  and  6.  Managed  object  class  definitions  shall  be 
provided  either  in  full  or  by  reference.  Registered  object  identifiers  shall  be  associated  with  any  such  managed 
object  class  definition  and  supporting  definitions  (e.g.,  attributes,  name  bindings).  All  mandatory  abstract 
syntaxes  and  semantics  associated  with  those  identifiers  shall  be  used.  Note  that  all  managed  objects  and 
supporting  definitions  in  Annex  A  satisfy  these  conformance  requirements. 

An  implementation  is  conformant  to  a  managed  object  class  definition  if  it  supports  all  the  mandatory  packages 
specified  in  the  managed  object  class  as  well  as  all  associated  information  (e.g.,  attributes,  notifications, 
actions,  parameters)  referenced  in  these  packages  and  at  least  one  name  binding  that  may  be  used  to  support 
the  naming  of  instances  of  this  managed  object  class.  Although  it  is  not  necessary  to  be  conformant  to  all 
superior  object  classes  in  the  containment  tree  of  an  instance  of  a  conformant  managed  object  class,  all  name 
bindings  and  naming  attributes  necessary  to  access  that  object  instance  shall  be  publicly  available. 
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8.3.3.1         MOCS  Proforma 

The  implementor  shall  provide  a  statement  specifying  which  nnanaged  object  classes  are  supported.  A  MOCS 
proforma  shall  be  completed  by  the  implementor  for  each  managed  object  class  supported. 

Editor's  Note:  [The  CD  Version  of  ISO/IEC  10165-6  (Requirements  and  Guidelines  for  Implementation 
Conformance  Statement  Proformas  Associated  with  Management  Information)  is  now 
available.  MOCS  Proformas  for  each  managed  object  class  supported  should  be  developed 
consistent  with  10165-6  [MOCS].] 

For  each  managed  object  class  supported,  the  following  shall  be  supplied: 

a)  a  statement  of  pragmatic  constraints  (e.g.,  attribute  values/ranges,  initial  values)  supported, 
unless  such  constraints  are  defined  in  the  managed  object  class  definition; 

b)  a  statement  of  conditional  packages  supported; 

c)  a  statement  of  role(s)  (manager,  agent,  or  both)  in  which  the  object  class  definition  is 
supported. 

Editor's  Note:  [CD  10165-6  does  not  currently  distinguish  roles.] 
8.3.4       Management  Application  Contexts 

The  implementation  shall  support  at  least  the  application  context  for  systems  management  defined  in  ISO/IEC 
10040  [SMO]. 

Note:    [Such  a  statement  is  required  by  [SMO]  clause  7.2.] 

Note:   [Such  a  statement  is  required  by  part  5,  clause  13.7,  which  discusses  conformance  requirements 
for  these  lAs,  as  related  to  services  required  of  the  upper  layers  and  other  ASEs.] 

8.4       Demonstration  of  Conformance 

(Refer  to  the  Working  Implementation  Agreements  Document.) 

8.4.1        Management  Communication 

(Refer  to  the  Working  Implementation  Agreements  Document.) 
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8.4.2  Management  Functions  and  Services 

(Refer  to  the  Working  Implementation  Agreements  Document.) 

8.4.3  Management  Information 

(Refer  to  the  Working  Implementation  Agreements  Document.) 
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Annex  A  (informative) 

Management  Information  Library  (MIL) 

(Refer  to  the  Working  Implementation  Agreements  Document  for  additional  information.) 
A.1  Introduction 

(Refer  to  the  Working  Implementation  Agreements  Document.) 
A.2  Rules  and  Procedures 

(Refer  to  the  Working  Implementation  Agreements  Document.) 
A.3  General  Guidelines 

(Refer  to  the  Working  Implementation  Agreements  Document.) 
A.4  Harmonized  Library 

The  definitions  specified  in  this  clause  can  be  referenced  by  using  the  label  "0P1  Library  Vol.  1"  (e.g.,  "0P1 
Library  Vol.  1":computerSystem). 

By  inclusion  of  the  managed  object  (MO)  definitions  and  the  object  identifiers  in  Annex  A  and  Annex  B, 
respectively,  of  the  Stable  Implementors'  Agreements  (SIAs),  these  managed  object  (MO)  definitions  have 
become  formally  registered.  Implementors  of  part  18  of  the  SIAs  do  not  have  to  support  any  of  these  MOs. 
However,  even  though  Annex  A  and  Annex  B  are  informative  annexes,  any  implementation  that  claims  to 
conform  to  these  definitions  must  treat  these  definitions  as  normative  and  comply  with  the  relevant  portions 
of  Annex  A.4  and  A.5,  and  Annex  B. 

A.4.1  Managed  Object  Classes  and  Mandatory  Packages 

A.4. 1.1  Computer  System 

computerSystem     MANAGED  OBJECT  CLASS 

DERIVED  FROM    "Rec,  X.721   j  ISO/IEC  10165-2  :  1992":top; 

CHARACTERIZED  BY  computerSystemPkg; 

CONDITIONAL  PACKAGES 

peripheralNamePkg  PRESENT  IF  !an  instance  supports  it  and  the 

peripheralListPkg  is  NOT  present!, 
peripheralListPkg  PRESENT  IF  !an  instance  supports  it  and  the 

peripheralNamePkg  is  NOT  present!, 
process ingEntityNamePkg    PRESENT  IF  !an  instance  supports  it  and  the 

processingEntityListPkg  is  NOT  present!, 
processingEntityListPkg    PRESENT  IF  !an  instance  supports  it  and  the 

process ingEntityNamePkg  is  NOT  present!. 
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systemTimePkg  PRESENT  IF  !an  instance  supports  it!, 

upTiinePkg  PRESENT  IF  !an  instance  supports  it!, 

"Rec.  M.3100  :  1992":userLabelPackage 

PRESENT  IF  !an  instance  supports  it!, 
usageStatePkg  PRESENT  IF  ! resource  can  detect  usage! ; 

REGISTERED  AS    {x-objectClass  1}; 


computerSystemPkg  PACKAGE 

BEHAVICXJR  computerSystemPkgDef inition, 
computerSystemPkgBehaviour; 

ATTRIBUTES 

computerSystemId  GET, 

"Rec.  X.721  !  ISO/IEC  10165-2  :  1992":operationalState  GET, 
"Rec.  X.721      ISO/IEC  10165-2  :  1992":administrativeState  GET-REPLACE, 
"Rec.  X.721      ISO/IEC  10165-2  :  1992":alarmStatus  GET-REPLACE  ADD-REMOVE, 
"Rec.  X.721  j  ISO/IEC  10165-2  :  1992":avai labi lityStatus  GET; 

ATTRIBUTE  GROUPS 

"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":state 

"Rec.  X.721  j  ISO/IEC  10i65-2  :  1992":administrati veState 
"Rec.  X.721      ISO/IEC  10165-2  :  1992":operationalState 
"Rec.  X.721      ISO/IEC  10165-2  :  1992":alarmStatus 
"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":avai labi lityStatus; 


NOTIFICATIONS 

"Rec.  X.721 

"Rec.  X.721 

"Rec.  X.721 

"Rec.  X.721 

"Rec.  X.721 

"Rec.  X,721 

"Rec.  X.721 


ISO/IEC  10165-2 

ISO/IEC  10165-2 

ISO/IEC  10165-2 

ISO/IEC  10165-2 

ISO/IEC  10165-2 

ISO/IEC  10165-2 

ISO/IEC  10165-2 


1 992 " :  ob  j  ec  t  C  rea  t  i  on , 

1992" robjectDelet ion, 

1992":attributeValueChange, 

1992":stateChange, 

1 992" : process  i  ngE  r rorA I  arm, 

1992":envi  ronmentalAlarm, 

1 992" : equ  i  pment A I  a rm; ; 


cotnputerSystemPkgDef  i  ni  t  i  on  BEHAVIOUR 
DEFINED  AS 

iThe  Computer  System  managed  object  class  represents  the  aggregate  of  components  which,  when 
considered  as  a  whole,  is  capable  of  performing  data  processing,  storage,  and  retrieval  functions. 
In  order  to  perform  its  function,  the  computer  system  may  have  a  variety  of  components  including 
processing  entities,  terminals,  disk  drives,  printers,  etc. 

The  Computer  System  is  intended  to  represent  an  aggregation  of  other  objects,  and  can  model  either 
self-contained  computer  systems  or  computer  systems  which  are  physically  distributed,  possibly  over 
a  wide  geographical  area.    An  instance  of  the  Computer  System  managed  object  class  may  have 
subordinate  managed  objects  representing  the  individual  entities  within  the  computer  system. 
Examples  are  entities  such  as  disks,  operating  systems  and  processing  entities. 

Since  the  Computer  System  may  be  physically  distributed,  it  is  not  appropriate  to  model  the  computer 
system  managed  object  class  as  a  subclass  of  the  Equipment  managed  object  class  (since  Equipment 
implies  a  single  physical  location  through  its  location  attribute).    However,  there  can  be  cases 
where  the  Computer  System  is  not  physically  distributed,  in  which  case  a  Name  Binding  allowing 
Computer  System  to  be  named  by  OMNIPoint  Equipment  is  permissible. 

It  is  not  appropriate  to  model  Computer  System  as  a  subclass  of  the  DMI  System  managed  object  class. 
Unlike  Computer  System,  the  DMI  System  is  a  "container"  object  class  which  is  instantiated  in 
managed  systems  and  exists  mainly  to  name  the  managed  and  support  objects  it  makes  visible.!; 


computerSystemPkgBehaviour  BEHAVIOUR 
DEFINED  AS 
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!A  value  for  the  conputerSystemld  attribute  can  only  be  provided  when  the  object  is  created. 
Furthermore,  this  attribute  value  may  not  change  once  the  managed  object  has  been  instantiated. 
Thus,  this  attribute  is  never  the  subject  of  an  AttributeValueChange  Notification. 

Conditions  under  which  an  AttributeValueChange  Notification  is  emitted  are  stated  in  the  behaviour 
of  the  appropriate  package  or  attribute.    In  the  absence  of  such  a  statement  in  the  behaviour,  the 
attribute  does  not  cause  an  AttributeValueChange  notification  to  be  emitted. 
All  attributeValueChange  notifications  shall  include  the  Attribute  Identifier  List  parameter. 

The  stateChange  notification  is  emitted  when  any  of  the  following  attributes  change  in  value: 
administrativeState,  operationalState,  and  availability  status. 

The  StateChange  notification  is  not  emitted  when  the  alarmStatus  attribute  changes  value.  (This  is 
to  avoid  duplication  of  notifications.) 

Since  every  combination  of  state  attribute  values  may  not  be  appropriate  for  particular  kinds  of 
computer  systems,  only  appropriate  combinations  need  be  supported. 

The  processingErrorAlarm  notification  is  emitted  when  the  computerSystem  resource  experiences  any  of 
the  alarm  conditions  defined  by  ISO/IEC  10164-4  (e.g.,  storage  capacity  problem,  version  mismatch, 
corrupt  data,  software  error,  underlying  resource  unavailable).!; 


A.4.1.2  Connection  Oriented  Transport  Protocol  Layer  Entity 


coTransportProtocolLayerEntity       MANAGED  OBJECT  CLASS 


DERIVED  FROM  "Rec.  X.721  j  ISO/IEC  10165-2  :  1992":top; 

CHARACTERIZED  BY  coTransportProtocolLayerEntityPkg; 


CONDITIONAL  PACKAGES 

manuf acturerL  i  stPkg 

manufacturerNamePkg 

productLabelPkg 

opVersionPkg 

serialNumberPkg 

typeTextPkg 

upTimePkg 

incomingProtocolErrorPkg 
'  '  outgoingProtocolErrorPkg 

checksumPDUsD i scardedPkg 
maxPDUSizelVPkg 


usageStatePkg 
REGISTERED  AS  Cx-objectClass  2>; 


PRESENT 

PRESENT 

PRESENT 
PRESENT 
PRESENT 
PRESENT 
PRESENT 
PRESENT 
PRESENT 
PRESENT 
PRESENT 
Connect 
provide 
PRESENT 


IF  !an  instance  supports  it  and  the 

manufacturerNamePkg  is  NOT  present!, 

IF  !an  instance  supports  it  and  the 

manufacturerListPkg  is  NOT  present!, 

IF  !an  instance  supports  it!, 

IF  !an  instance  supports  it!, 

IF  !an  instance  supports  it!, 

IF  !an  instance  supports  it!, 

IF  !an  instance  supports  it!, 

IF  !an  instance  supports  it!, 

IF  !an  instance  supports  it!, 

IF  !an  instance  supports  it!, 

IF  !the  "OPI  Library  Vol.  2  :  1992": transport 
ionlVMO  object  class  is  not  used  to 

this  initial  value!, 

IF  ! resource  can  detect  usage!; 


coT  ranspor tProtoco I LayerEnt  i  tyPkg  PACKAGE 

BEHAVIOUR    coTransportProtocolLayerEntityPkgDef inition, 
coT  ranspor tProtoco I LayerEnt  i  tyPkgBehavi  our ; 

ATTRIBUTES 

coTransportProtocolLayerEntityld   PERMITTED  VALUES  SYNTAX-1 .GraphicString64  GET, 

transportEntityType  GET, 

I oca  IT ranspor tAddresses  GET, 

act iveConnect ions    PERMITTED  VALUES  SYNTAX-1 . Integer32  GET, 
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maxConnections     PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
"Rec.  X.721 
"Rec.  X.721 


!  I  SO/ 1 EC 
ISO/IEC 


"Rec.  X.721 

"Rec.  X.721 

"Rec.  X.721 

"Rec.  X.721 

"Rec.  X.721 

"Rec.  X.721 

"Rec.  X.721 

"Rec.  X.721 

"Rec.  X.721 

"Rec.  X.721 

"Rec.  X.721 


ATTRIBUTE  GROUPS 
"Rec.  X.721 


ISO/IEC 
j  ISO/IEC 

ISO/IEC 

ISO/IEC 

ISO/IEC 

ISO/IEC 

ISO/IEC 

ISO/IEC 

ISO/IEC 

ISO/IEC 

ISO/IEC 


10165-2 
10165-2 
10165-2 
10165-2 


10165-2 


10165-2 


10165-2 


10165-2 


10165-2 


10165-2 


10165-2 


10165-2 


10165-2 


1992":administrativeState  GET-REPLACE, 
1992":operationalState  GET, 
1992":alarmStatus  GET-REPLACE  ADO-REMOVE, 
1992":outgoingConnectionRequestsCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
1992" : i  ncomi  ngConnect  i  onRequestsCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
1 992" : out  go  i  ngConnect  i  onRe  j  ec t E  r  rorCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
1992" : i  ncotni  ngConnect  i  onRe  jectErrorCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
1992" : outgo  i  ngD  i  sconnec tE  rrorCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
1992": incomingDisconnectErrorCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
1992" : i  ncomi  ngD  i  sconnectCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
1992" : outgoi  ngD  i  sconnectCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
1992" : octetsSentCounter 

PERMITTED  VALUES  SYNTAX-1 . Integer32  GET, 
1992":octetsReceiveclCounter 

PERMITTED  VALUES  SYNTAX-1 . Integer32  GET; 


ISO/IEC  10165-2  :  1992":state 
Rec.  X.721  j  ISO/IEC  10165-2 
Rec.  X.721      ISO/IEC  10165-2 
Rec.  X.721  !  ISO/IEC  10165-2 


1992":adniinistrativeState 
1 992" : operat  i  ona I  State 
1992":alarmStatus; 


ACTIONS      activate,  deactivate; 


NOTIFICATIONS 
"Rec.  X.721 
"Rec.  X,721 
"Rec,  X.721 
"Rec.  X.721 
"Rec.  X.721 


ISO/IEC  10165-2 

ISO/IEC  10165-2 

ISO/IEC  10165-2 

ISO/IEC  10165-2 

ISO/IEC  10165-2 


1992" :objectCreat ion, 

1992" robjectDelet ion, 

1 992" :  a  1 1  r  i  but  eVa  I  ueChange , 

1992":stateChange, 

1992":processingErrorAlarm; ; 


coTransportProtocolLayerEntityPkgDef inition  BEHAVIOUR 
DEFINED  AS 

!The  coTransportProtocolLayerEntity  managed  object  class  represents  an  instantiation   of  any 
connect  ion- oriented  transport  layer  protocol  (e.g.,  the  ISO  Transport  Protocol      layer  or  the 
Internet  Transmission  Control  Protocol  (TCP)  Layer).    The  transport     protocol  layer  is  layer  four 
of  the  OSI  Reference  model.    It  provides  for  the     transparent  transference  of  data  between  two  peer 
entities.    It  relieves  its  users     from  any  concerns  about  the  detailed  way  in  which  supporting 
communication  media  are     utilized  to  achieve  this  transfer.    The  connect  ion- oriented  transport 
protocol  layer     entity  makes  use  of  a  transport  connection  for  the  purpose  of  transferring  data. 

This  is  a  generally  applicable  managed  object  class,  in  that  it  does  not  represent  any  specific 
connection-oriented  transport  protocol  -  rather  it  contains  characteristics  common  across  various 
different  connect  ion- oriented  transport  layer  protocols.    This  managed  object  class  is  not  intended 
to  override  any  transport  layer  managed  object  classes  defined  in  ISO.    It  provides  a  high  level 
view  of  a  connection-oriented  transport  layer  protocol  and  complements  the  protocol-specific  views 
being  defined  in  the  standards.!; 


coTransportProtocolLayerEntityPkgBehaviour  BEHAVIOUR 
DEFINED  AS 
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IConditions  under  which  an  attributeValueChange  notification  is  emitted  are  stated  in  the  behaviour 
of  the  appropriate  package  or  attribute.  In  the  absence  of  such  a  statement,  in  the  behaviour,  the 
attribute  does  not  cause  an  attriixiteValueChange  to  Be  emitted. 

The  attributeValueChange  notification  is  emitted  when  any  of  the  following  attributes  change  in 
value:  localTransportAddresses,  maxConnections,  transportEntityType,  and  all  counter  attributes 
(only  when  they  wrap).    All  attributeValueChange  notifications  shall  include  the  Attribute 
Identifier  List  parameter.    All  attributeValueChange  notifications  which  report  counter  attribute 
wraps  shall  contain  the  maximum  counter  attribute  value  in  the  Old  Attribute  Value  parameter. 

The  stateChange  notification  is  emitted  when  any  of  the  following  attributes  change  in  value: 
administrativeState  and  operationalState. 

The  processingErrorAlarm  notification  is  emitted  when  the  coTransportProtocolLayerEntity  resource 
experiences  any  of  the  alarm  conditions  defined  by  ISO/IEC  10164-4  (e.g.,  storage  capacity  problem, 
version  mismatch,  corrupt  data,  software  error,  underlying  resource  unavailable).!; 

This  is  a  generally  applicable  managed  object  class,  in  that  it  does  not  represent  any  specific  connection- 
oriented  transport  protocol.    ISO/IEC  10733  [TLM]  defines  specific  objects  for  managing  OSI  transport 
protocol  layer  entities. 

A.4.1.3  Connectionless  Network  Protocol  Layer  Entity 


clNetworkProtocolLayerEntity       MANAGED  OBJECT  CLASS 

DERIVED  FROM  "Rec.  X.721  j  ISO/IEC  10165-2  :  1992":  top; 

CHARACTERIZED  BY  clNetworkProtocolLayerEntityPkg; 


CONDITIONAL  PACKAGES 


manuf acturerL  i  stPkg 

manufacturerNamePkg 

productLabelPkg 

opVersionPkg 

serialNumberPkg 

typeTextPkg 

upTimePkg 


PRESENT  IF  fan  instance  supports  it  and  the 

manufacturerNamePkg  is  NOT  present!, 
PRESENT  IF  !an  instance  supports  it  and  the 

manufacturerListPkg  is  NOT  present!, 
PRESENT  IF  !an  instance  supports  it!, 
PRESENT  IF  !an  instance  supports  it!, 
PRESENT  IF  !an  instance  supports  it!, 
PRESENT  IF  !an  instance  supports  it!, 
PRESENT  IF  Ian  instance  supports  it!; 


REGISTERED  AS    Cx-objectClass  3>; 


c I NetworkProtocol LayerEnt  i  tyPkg  PACKAGE 

BEHAVIOUR    clNetworkProtocolLayerEntityPkgDef inition, 
c iNetworkProtocol LayerEnt i tyPkgBehavi our ; 

ATTRIBUTES 

clNetworkProtocolLayerEntityld  PERMITTED  VALUES  SYNTAX-1.GraphicString64  GET, 
networkEntityType  GET, 

localNetworkAddresses    GET -REPLACE  ADD -REMOVE, 

nPDUTimeToLive    PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET-REPLACE, 

"Rec.  X.721  !  ISO/IEC  10165-2  :  1992":administrati veState  GET-REPLACE, 

"Rec.  X.721      ISO/IEC  10165-2  :  1992":operationalState  GET, 

"Rec.  X.721      ISO/IEC  10165-2  :  1992":alarmStatus    GET-REPLACE  ADD-REMOVE, 

"Rec.  X.721  I  ISO/IEC  10165-2  :  1992»:pdusSentCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
"Rec.  X.721  j  ISO/IEC  10165-2  :  1992":pdusReceivedCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
"Rec.  X.721  j  ISO/IEC  10165-2  :  1992":octetsSentCounter 

PERMITTED  VALUES  SYNTAX- 1 .Integer32  GET, 
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"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":octetsReceivedCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
pdusForwardedCounter    PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
pdusReasmbldOKCounter    PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
pdusReasmbldFailCounter    PERMITTED  VALUES  SYNTAX-1 . Integer32  GET, 
pdusDiscardedCounter     PERMITTED  VALUES  SYNTAX-1 . Integer32  GET; 

ATTRIBUTE  GROUPS 

"Rec.  X.721  j  ISO/IEC  10165-2  :  1992":state 

"Rec.  X.721  !  ISO/IEC  10165-2  :  1992":administrativeState 
"Rec.  X.721      ISO/IEC  10165-2  :  1992":operationalState 
"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":alarmStatus; 

ACTIONS      activate,  deactivate; 

NOTIFICATIONS 

"Rec.  X.721  {  ISO/IEC  10165-2  :  1992":objectCreation, 

"Rec.  X.721  ISO/IEC  10165-2  :  1992":objectDeletion, 

"Rec.  X.721  ISO/IEC  10165-2  :  1992":attributeValueChange, 

"Rec.  X.721  ISO/IEC  10165-2  :  1992":processingErrorAlarm, 

"Rec.  X.721  ISO/IEC  10165-2  :  1992":coiTmunicationsAlarm, 

"Rec.  X.721  !  ISO/IEC  10165-2  :  1992":stateChange;; 


clNetworkProtocolLayerEntityPkgDef inition  BEHAVIOUR 
DEFINED  AS 

!The  clNetworkProtocolLayerEnti ty  managed  object  class  represents  an  instantiation  of  a 
connectionless  network  protocol  layer.    The  network  protocol  layer  provides  network  services  for  the 
transparent  transfer  of  data  between  peer  transport  entities.    It  relieves  the  transport  protocol 
layer  from  the  need  to  know  anything  about  the  underlying  network  technologies  used  to  achieve  data 
transfer. 

This  is  a  generally  applicable  managed  object  class,  in  that  it  does  not  represent  any  specific 
connectionless  network  protocol;  instead,  it  contains  characteristics  common  across  various 
different  connectionless  network  layer  protocols.    This  managed  object  class  is  not  intended  to 
override  any  network  layer  managed  object  classes  defined  in  ISO.    It  provides  a  high  level  view  of 
a  connectionless  network  layer  protocol  and  complements  the  protocol -specific  views    being  defined 
in  the  standards. 

An  instance  of  this  managed  object  class  supports  only  one  type  of  protocol.!; 
ClNetworkProtocolLayerEnti tyPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

IConditions  under  which  an  attributeValueChange  notification  is  emitted  are  stated  in  the  behaviour 
of  the  appropriate  package  or  attribute.  In  the  absence  of  such  a  statement,  in  the  behaviour,  the 
attribute  does  not  cause  an  attributeValueChange  to  be  emitted. 

The  attributeValueChange  notification  is  emitted  when  any  of  the  following  attributes  change  in 
value:  networkEntityType,  localNetworkAddresses,  nPDUTimeToLive,  and  all  counter  attributes  (only 
when  they  wrap).    All  attributeValueChange  notifications  shall  include  the  Attribute  Identifier  List 
parameter.    All  attributeValueChange  notifications  which  report  counter  attribute  wraps  shall 
contain  the  maximum  counter  attribute  value  in  the  Old  Attribute  Value  parameter. 

The  stateChange  notification  is  emitted  when  any  of  the  following  attributes  change  in  value: 
administrativeState  and  operationalState. 

The  communicationsAlarm  notification  is  emitted  when  the  clNetworkProtocolLayerEntity  resource 
experiences  any  of  the  alarm  conditions  defined  by  ISO/lEC  1016A-4  (e.g.,  loss  of  signal,  local 
transmission  error,  remote  transmission  error).    In  particular,  this  notification  is  used  to  report 
when  a  data  NPDU  is  discarded  for  any  reason  other  than  network  congestion. 
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The  processingErrorAlarm  notification  is  emitted  when  the  clNetworkProtocolLayerEntity  resource 
experiences  any  of  the  alarm  conditions  defined  by  ISO/IEC  10164-4  (e.g.,  storage  capacity  problem, 
version  mismatch,  corrupt  data,  software  error,  underlying  resource  unavailable).!; 

This  is  a  generally  applicable  managed  object  class,  in  that  it  does  not  represent  any  specific 
connectionless  network  protocol.    ISO/IEC  10737  [NLM]  defines  specific  objects  for  managing  OSI  network 
protocol  layer  entities. 


A.4.1.4  OMNIPoint  Equipment 


This  definition  is  subclassed  from  CCITT  M.3100  Equipment,  adding  the  following  items: 

Mandatory  AttributeChange,  ObjectCreation,  ObjectDeletion  Notifications 
Mandatory  Environmental,  Processing  Error,  and  Equipment  Alarm  Notifications 
Mandatory  Administrative  and  Operational  State  Attributes  and  State  Change  Notification 
CREATE/DELETE  operations  and  behaviours  (in  nanne  bindings) 

Conditional  Contact,  Customer,  Function,  Manufacturer,  OMNIPoint  Network,  Service,  Software 

and  Vendor  Name  and  List  Packages 

Conditional  Product  and  Serial  Number  Packages 

Conditional  Type  Text  Package 

Conditional  Location  Pointer  Package 

--  ANSI  T1M1.5  concerns  regarding  physical  vs.  functional  modelling  were  resolved  by  excluding  the  Forum 
--  R1  Equipment  Type  attribute  from  the  OMNIPoint  definition.    The  TypeText,  FunctionName,  and/or 
--  FunctionList  attributes  may  be  used  to  carry  (as  graphic  strings  or  pointers)  information  concerning 
--  the  function(s)  supported  by  the  physical  Equipment.    It  is  expected  that  Forum  R1  to  OMNIPoint  1 

mapping  rules  will  define  a  translation  between  Forum  R1  EquipmentType  enumerations  and  these  OMNIPoint 
--  Equipment  attributes. 


opEquipment  MANAGED  OBJECT  CLASS 

DERIVED  FROM    "Rec.  M.3100  :  1 992" -.equipment ; 


CHARACTERIZED  BY 

opEquipmentPkg, 

"Rec.  M.3100  :  1992":createDeleteNotif icationsPackage, 

.   "Rec.  M.3100  :  1992":attributeValueChangeNotif icationPackage, 

"Rec.  M.3100  :  1992" :stateChangeNot if icationPackage, 

"Rec.  M.3100  :  1992":administrativeOperationalStatesPackage, 

"Rec.  M.3100  :  1992":environmentalAlarmPackage, 

"Rec.  M.3100  :  1992":processingErrorAlarmPackage, 

"Rec.  M.3100  :  1992":equipmentsEquipmentAlarmPackage; 


CONDITIONAL  PACKAGES 


contactListPkg 

PRESENT 

contactNamePkg 

PRESENT 

customerListPkg 

PRESENT 

customerNamePkg 

PRESENT 

functionListPkg 

PRESENT 

functionNamePkg 

PRESENT 

locationPointerPkg 

PRESENT 

manuf acturerL  i  s tPkg 

PRESENT 

manufacturerNamePkg 

PRESENT 

IF  <an  instance  supports  it  and  the 

contactNamePkg  is  NOT  present!, 
IF  !an  instance  supports  it  and  the 

contactListPkg  is  NOT  present!, 
IF  !an  instance  supports  it  and  the 

customerNamePkg  is  NOT  present!, 
IF  !an  instance  supports  it  and  the 

customerListPkg  is  NOT  present!, 
IF  !an  instance  supports  it  and  the 

functionNamePkg  is  NOT  present!, 
IF  !an  instance  supports  it  and  the 

functionListPkg  is  NOT  present!, 
IF  !an  instance  supports  it  and  the 

"Rec.  M.3100  :  1992": 

locationNamePackage  is  NOT  present!, 
IF  !an  instance  supports  it  and  the 

manufacturerNamePkg  is  NOT  present!, 
IF  !an  instance  supports  it  and  the 
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sof twareListPkg 


typeTextPkg 

usageStatePkg 

vendorListPkg 


productLabelPkg 
serialNumberPkg 
serviceListPkg 


opVersionPkg 


opNetMorkListPkg 


serviceNamePkg 


opNetMorkNamePkg 


sof twareNamePkg 


manufacturerListPkg  is  NOT  present!, 
PRESENT  IF  !an  instance  supports  it  and  the 

opNetworkNamePkg  is  NOT  present!, 
PRESENT  IF  !an  instance  supports  it  and  the 

opNetworkListPkg  is  NOT  present!, 
PRESENT  IF  !"Rec.  M.3100  :  1992": 

versionPackage  is  also  present!, 
PRESENT  IF  !an  instance  supports  it!, 
PRESENT  IF  !an  instance  supports  it!, 
PRESENT  IF  !an  instance  supports  it  and  the 

serviceNamePkg  is  NOT  present!, 
PRESENT  IF  !an  instance  supports  it  and  the 

serviceListPkg  is  NOT  present!, 
PRESENT  IF  !an  instance  supports  it  and  the 

sof twareNamePkg  is  NOT  present!, 
PRESENT  IF  !an  instance  supports  it  and  the 

sof twareListPkg  is  NOT  present!, 
PRESENT  IF  !an  instance  supports  it!, 
PRESENT  IF  ! resource  can  detect  usage!, 
PRESENT  IF  !an  instance  supports  it  and  the 

"Rec.  M.3100  :  1992": 

vendorNamePackage  is  NOT  present!; 


REGISTERED  AS    Cx-objectClass  4>; 


opEquipmentPkg 


PACKAGE 


BEHAVI OUR  opEqui pmentPkgBehavi our ; 

--    opEquipmentPkgDef inition  inherited  from  Rec.  M.3100  Equipment 

ATTRIBUTES 

"Rec.  M.3100  :  1992": equipment  Id  PERMITTED  VALUES  SYNTAX- 1 .Equipment  I dRange  GET; 

ATTRIBUTE  GROUPS 

"Rec.  X.721  i  ISO/IEC  10165-2  :  1992":state 

"Rec.  X.721  !  ISO/IEC  10165-2  :  1992":administrativeState 
"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":operationalState; ; 


opEqui pmentPkgBehavi our  BEHAVIOUR 

DEFINED  AS  --  inherited  from  Rec.  M,3100  Equipment,  with  the  following  extensions: 

lA  value  for  the  "Rec.  M.3100  :  1992":equipmentld  attribute  can  only  be  provided  when  the  object  is 
created.    Furthermore,  this  attribute  value  may  not  change  once  the  managed  object  has  been 
instantiated.    Thus,  this  attribute  is  never  the  subject  of  an  AttributeValueChange  Notification. 


Conditions  under    which  an  AttributeValueChange  Notification  is  emitted  are  stated  in  the  behaviour 
of  the  appropriate  package  or  attribute.    In  the  absence  of  such  a  statement  in  the  behaviour,  the 
attribute  does  not  cause  an  AttributeValueChange  notification  to  be  emitted. 
All  attributeValueChange  notifications  shall  include  the  Attribute  Identifier  List  parameter. 

The  processingErrorAlarm  notification  (if  present)  is  emitted  when  the  Equipment  resource 
experiences  any  of  the  alarm  conditions  defined  by  ISO/IEC  10164-4  (e.g.,  storage  capacity  problem, 
version  mismatch,  corrupt  data,  software  error,  underlying  resource  unavailable).!; 


A.4.1.5  OMNIPoint  Network 

--  This  definition  is  subclassed  from  Rec.  M.3100  Network,  adding  the  following  items: 

Network  Title  and  associated  name  binding  to  Root 
AttributeChange,  ObjectCreation,  ObjectDeletion  Notifications 
CREATE/DELETE  operations  and  behaviours  (in  name  bindings) 
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opNetwork  MANAGED  OBJECT  CLASS 

DERIVED  FROM  "Rec.  M.3100  :  1992":network; 
CHARACTERIZED  BY  opNetworkPkg; 

REGISTERED  AS    (x-objectClass  5>; 


opNetworkPkg  PACKAGE 

BEHAVIOUR  opNetworkPkgBehaviour; 

--  opNetworkPkgDef inition  inherited  from  Rec.  M.3100  Network 

ATTRIBUTES 

networkTitle  GET; 

NOTIFICATIONS 

"Rec.  X.721  j  ISO/IEC  10165-2  :  1992":objectCreation, 

"Rec.  X.721      ISO/IEC  10165-2  :  1992":objectDeletion, 

"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":attributeValueChange;; 


opNetworkPkgBehaviour  BEHAVIOUR 

DEFINED  AS  --  inherited  from  Rec.  M.3100  Network,  with  the  following  extensions: 

•Values  for  the  Network  Identifier  and  Network  Title  attributes  can  only  be  provided  when  the  object 
is  created.    Furthermore,  these  attribute  values  may  not  change  once  the  managed  object  has  been 
instantiated.    Thus,  they  are  never  the  subject  of  an  AttributeValueChange  Notification.  When 
NetworkTitle  is  used  for  naming,  the  Network  Identifier  attribute  has  a  NULL  value. 

Conditions  under  which  an  AttributeValueChange  Notification  is  emitted  are  stated  in  the  behaviour 
of  the  appropriate  package  or  attribute.    In  the  absence  of  such  a  statement  in  the  behaviour,  the 
attribute  does  not  cause  an  AttributeValueChange  notification  to  be  emitted.  All 
attributeValueChange  notifications  shall  include  the  Attribute  Identifier  List  parameter.!; 


A.4.1.6  Processing  Entity 

process ingEntity  MANAGED  OBJECT  CLASS 

DERIVED  FROM  opEquipment; 

CHARACTERIZED  BY    process ingEntityPkg; 

CONDITIONAL  PACKAGES 

addressingPkg  PRESENT  IF  Irelevant  to  the  underlying  resource!, 

cpuUti lizationPkg      PRESENT  IF  !an  instance  supports  it!, 
memorySizePkg  PRESENT  IF  'relevant  to  the  underlying  resource!, 

memoryUti lizationPkg  PRESENT  IF  Ian  instance  supports  it!, 
upTimePkg  PRESENT  IF  !an  instance  supports  it!; 

REGISTERED  AS    Cx-objectClass  6>; 

process ingEntityPkg  PACKAGE 

BEHAVI OUR  process i ngEnt  i  tyPkgDef  i ni  t i on, 
process  i  ngEnt  i  tyPkgBehavi  our; 

ATTRIBUTES 

cpuType  PERMITTED  VALUES  SYNTAX-1 .GraphicString16  GET, 

OSlnfo  PERMITTED  VALUES  SYNTAX- 1 .OsInfoRange  GET;; 


40 


PART  1 8:  Network  Management 


December  1992  (Stable) 


process ingEntityPkgDefi nit  ion  BEHAVIOUR 
DEFINED  AS 

!The  process ingEntity  managed  object  class  represents  the  physical  portion  of  the  computer  system 
that    performs  a  processing  function,  frequently  called  a  Central  Processing  Unit  (CPU).  A 
Processing  Entity  may  be  composed  of  such  components  as  arithmetical  logical  units  (ALU), 
registers  for  processing  memory,  limited  storage  most  often  in  the  form  of  Random  Access  Memory 
(RAM),  and  various    other  types  of  memory  used  in  the  processing  function.    It  does  not  include  such 
components  as  disk  drives,  data  bases,  etc. 

Some  Processing  Entities  may  have  input/output  channels,    particularly  when  hardware  is  shared 
between  elements    of  the  Processing  Entity.    In  other  cases,  the  input/output    must  be  seen  as 
components  of  a  superior  managed  object,  for    example  a  Computer  System,  or  as  OMNI  Point  Equipment 
objects  shared  among  several  Computer  Systems. 

The  cpuType  attribute  indicates  the  type  of  central  processor  unit  found  in  the  Processing  Entity. 

The  oslnfo  attribute  specifies  the  names  and  releases  of  the  supported  operating  systems.!; 
process  i  ngEnt  i  tyPkgBehav  i  our  BEHAV I OUR 

DEFINED  AS 

■The  AttributeValueChange  notification  is  emitted  when  any  of  the  following  attributes  change  in 
value:  cpuType  or  oslnfo.!; 


A.4.1.7  Transport  Connection 

transportConnection  MANAGED  OBJECT  CLASS 

DERIVED  FROM    "Rec.  X.721  \  ISO/IEC  10165-2  :  1992":  top; 

CHARACTERIZED  BY  transportConnectionPkg; 

CONDITIONAL  PACKAGES 

maxRet  ransmi  ss  i  onsPkg 
ret  ransmi  ss  i  onT  i  mePkg 
ret  ransmi  ss  i  onT  imer I ni  t  i  a  I Va I uePkg 
pdusRetransmi  ttedCounterPkg 
octetsRetransmi  ttedPkg 
pdusRetransmi ttedThresholdPkg 
outgoingProtocoLErrorPkg 
checksumPDUsD  i  scardedPkg 

REGISTERED  AS  <x-objectClass  7>; 


transportConnectionPkg  PACKAGE 

BEHAVIOUR    transportConnectionPkgDef inition, 
transportConnect ionPkgBehaviour; 

ATTRIBUTES 

transportConnect ionid    PERMITTED  VALUES  SYNTAX- 1 .GraphicString6A  GET, 
loca I TransportConnect i onEndpoi nt  GET , 
remoteTransportConnectionEndpoint  GET, 

transportConnectionReference    PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
localNetworkAddress  GET, 
remoteNetworkAddress  GET, 

inactivityTimeout    PERMITTED  VALUES  SYNTAX- 1. I nteger32  GET, 
inactivityTime  PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
maxPDUSize    PERMITTED  VALUES  SYNTAX-1 . Integer32  GET, 
"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":pdusSentCounter 


PRESENT 

IF 

PRESENT 

IF 

PRESENT 

IF 

PRESENT 

IF 

PRESENT 

IF 

PRESENT 

IF 

PRESENT 

IF 

PRESENT 

IF 

■an  instance 

■an  instance 

fan  instance 

!an  instance 

jan  instance 

fan  instance 

fan  instance 

fan  instance 


supports  it 
supports  it 
supports  it 
supports  it 
supports  it 
supports  it 
supports  it 
supports  it 
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"Rec. 

X.721 

I  SO/ 1  EC 

10165 

-2 

"Rec. 

X.721 

I  SO/ 1  EC 

10165 

-2 

"Rec. 

X.721 

I  SO/ 1  EC 

10165 

-2 

"Rec. 

X.721 

I  SO/ 1  EC 

10165 

-2 

NOTIFICATIONS 
"Rec.  X.721 
"Rec.  X.721 
"Rec.  X.721 


t  ranspor t Connec  t  i  onPkgDef  i  n  i  t  i  on   BE  H AV I OUR 


PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
1 992" : pdusRece  i  vedCounter 

PERMITTED  VALUES  SYNTAX- 1 , Integer32  GET, 
1992":octetsSentCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
1992" roctetsRecei vedCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
1992": incomingProtocolErrorCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET; 


j  ISO/IEC  10165-2  :  1992":objectCreation, 

ISO/IEC  10165-2  :  1992":objectDeletion  transportOisconnectCause, 
I  ISO/IEC  10165-2  :  1992":attributeValueChange;; 


DEFINED  AS 

!The  transportConnection  managed  object  class  represents  an  active  transport  connection  (e.g.,  an 
OSI  transport  connection  or  a  TCP  connection).    A  transport  connection  is  established  and  used  by 
two  peer  connection  oriented  transport  protocol  layer  entities  for  the  purpose  of  transferring  data. 
A  connection  oriented  transport  protocol  layer  entity  may  support  multiple  transport  connections. 

This  is  a  generally  applicable  managed  object  class,  in  that  it  does  not  represent  any  specific 
connection-oriented  transport  protocol;  rather  it  contains  characteristics  common  across  various 
different  connection-oriented  transport  layer  protocols.    This  managed  object  class  is  not  intended 
to  override  any  transport  layer  managed  object  classes  defined  in  ISO.    It  provides  a  high  level 
view  of  a  connect  ion- oriented  transport  layer  protocol  and  complements  the  protocol -specific  views 
being  defined  in  the  standards.!; 


t  ransportConnect  i  onPkgBehavi  our    BEHAVI OUR 


DEFINED  AS 

!An  instance  of  the  Transport  Connection  managed  object  class  is  created  automatically  in  response 
to  normal  operation  of  the  network,    A  prerequisite  to  the  creation  of  a  transport  connection  is  the 
existence  of  a  transport  entity  (e.g.  an  instance  of  the  Connection  Oriented  Transport  Protocol 
Layer  Entity)  on  the  open  system.  When  a  new  Transport  Connection  instance  is  created,  the  "0P1 
Library  Vol.  2  :  1992":transportConnectionIVM0  instance  with  the  same  superior  may  be  used  to 
provide  initial  attribute  values  for  the  new  instance.    Alternatively,  the  Maximum  PDU  Size 
attribute  takes  on  the  value  of  the  Maximum  PDU  Size  attribute  specified  in  the  superior  Transport 
Protocol  Layer  Entity  managed  object  instance.  Subsequently  the  Maxiinum  PDU  Size  attribute  may  take 
on  another  value  which  applies  specifically  to  the  connection  represented  by  the  instantiation  of 
the  transport  connection.    This  change  may  occur  as  the  result  of  peer  protocol  negotiation. 

The  Additional  Information  parameter  of  the  objectDeletion  notification  may  optionally  contain  a 
management  extension  (as  defined  in  OMI)  whose  identifier  is  that  of  the  "cause"  attribute,  whose 
significance  is  FALSE,  and  whose  information  is  "cause"  as  defined  in  the  associated  PARAMETER 
template. 

Conditions  under  which  an  attributeValueChange  notification  is  emitted  are  stated  in  the  behaviour 
of  the  appropriate  package  or  attribute.    In  the  absence  of  such  a  statement,  in  the  behaviour,  the 
attribute  does  not  cause  an  attributeValueChange  to  be  emitted. 

The  attributeValueChange  notification  is  emitted  when  any  of  the  following  attributes  change  in 
value:  inactivi tyTimeout,  maxPDUSize,  and  all  counter  attributes  (only  when  they  wrap).  All 
attributeValueChange  notifications  shall  include  the  Attribute  Identifier  List  parameter.  All 
attributeValueChange  notifications  which  report  counter  attribute  wraps  shall  contain  the  maximum 
counter  attribute  value  in  the  Old  Attribute  Value  parameter. 

Transport  Connection  will  delete  itself  when  the  value  of  the  inactivityTime  attribute  equals  that 
of  the  inactivi tyTimeout  attribute.!; 
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This  is  a  generally  applicable  managed  object  class,  in  that  it  does  not  represent  any  specific  connection' 
oriented  transport  protocol.    ISO/IEC  10733  [TLM]  defines  specific  objects  for  managing  OSI  transport 
protocol  layer  entities. 

A.4.2  Conditional  Packages 


A.4.2.1  Addressing  Package 

address ingPkg  PACKAGE 

BEHAVIOUR      address  i  ngPkgDef  i  ni  t  i  on, 
address ingPkgBehavi our; 

ATTRIBUTES     address ingSize     PERMITTED  VALUES  SYNTAX- 1 .AddressingSizeRange  GET, 
endianess  GET; 
REGISTERED  AS  Cx-package  1>; 

addressingPkgDefinition  BEHAVIOUR 

DEFINED  AS 

■This  package  defines  the  addressing  size  and  endianess  which  are  characteristic  of  the  underlying 
resource.!; 

addressingPkgBehaviour  BEHAVIOUR 

DEFINED  AS 

I  If  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  uhen  the  address ingSize  or  endianess  attributes  change 
value. I ; 

A.4.2.2  Checksum  PDUs  Discarded  Package 

checksumPDUsDiscardedPkg  PACKAGE 

8EHAVI OUR    checksumPDUsD  i  scardedPkgDef  i  ni  t  i  on, 
checksumPDUsD i scardedPkgBehavi our ; 

ATTRIBUTES 

ChecksumPDUsD iscardedCounter  PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET; 
REGISTERED  AS    <x- package  2}; 


ChecksumPDUsD  i  scardedPkgDef  i  ni  t  i  on   BE  HAV I OUR 
DEFINED  AS 

(This  package  reflects  the  capability  of  the  underlying  resource  to  count  the  number  of  well-formed 
PDUs  rejected  by  the  peer  entity  due  to  a  checksum  error.!; 


ChecksumPDUsD  i  scardedPkgBehav  i  our    BEHAV I OUR 
DEFINED  AS 

!If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  checksumPDUsD iscarded  attribute  wraps.!; 


A.4.2.3  Contact  List  Package 

contactListPkg  PACKAGE 
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BEHAVIOUR  contactListPkgOefinition, 
contactL  i  stPkgBehavi  our; 

ATTRIBUTES     contactList    PERMITTED  VALUES  SYNTAX- 1 .AnyNamesRange    GET-REPLACE  AOO-REMOVE; 

REGISTERED  AS  {x-package  3>; 


contactL istPkgOefi nit  ion  BEHAVIOUR 
DEFINED  AS 

IThe  Contact  List  Attribute  identifies  who  (person  or  organization)  should  be  contacted  about  the 
resource. I ; 

contactL i StPkgBehavi our  BEHAVIOUR 

DEFINED  AS 

■If  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  contactList  attribute  changes  value. I; 

A.4.2.4  Contact  Name  Package 

contactNamePkg  PACKAGE 

BEHAVIOUR  contactNamePkgDef inition, 
contactNamePkgBehaviour; 

ATTRIBUTES     contactName    PERMITTED  VALUES  SYNTAX- 1 .AnyNameRange  GET-REPLACE; 

REGISTERED  AS  Cx-package  4}; 


contactNamePkgDef inition  BEHAVIOUR 
DEFINED  AS 

!The  Contact  Name  Attribute  identifies  who  (person  or  organization)  should  be  contacted  about  the 
resource.!; 

contactNamePkgBehaviour  BEHAVIOUR 

DEFINED  AS 

I  If  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  contactName  attribute  changes  value.!; 

A.4.2.5  CPU  Utilization  Package 

cpuUtilizationPkg  PACKAGE 

BEHAVIOUR       cpuUti lizationPkgBehaviour; 

ATTRIBUTES     cpuUti lization     PERMITTED  VALUES  SYNTAX- 1 .PercentageRange 

GET;  --    changed  from  GET-REPLACE  (Forum) 

REGISTERED  AS  {x-package  5>; 

cpUUt  i I i  zat { onPkgBehavi  our    BEHAVI OUR 

DEFINED  AS 

!Even  if  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  NOT  emitted  when  the  cpuUt i I i zat i on  attribute  changes  value.!; 

A.4.2.6  Customer  List  Package 
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customerListPkg  PACKAGE 

BEHAVIOUR  customerL i s tPkgDef  i ni  t  i on, 
customerListPkgBehaviour; 

ATTRIBUTES    customerL i St  PERMITTED  VALUES  SYNTAX- 1 .AnyNamesRange  GET-REPLACE  ADD-REMOVE; 

REGISTERED  AS  <x-package  6>; 

customerListPkgDefinition  BEHAVIOUR 

DEFINED  AS 

IThe  Customer  List  attribute  identifies  any  customers  that    are  users  of  the  resource.!; 
customerL  i  stPkgBehavi  our    BEHAVI OUR 
DEFINED  AS 

!If  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  customerList  attribute  changes  value. !; 

A.4.2.7  Customer  Name  Package 

customerNamePkg  PACKAGE 

BEHAVIOUR  customerNamePkgDef inition, 
customerNamePkgBehaviour; 

ATTRIBUTES    customerName  PERMITTED  VALUES  SYNTAX- 1 .AnyNameRange  GET-REPLACE; 

REGISTERED  AS  Cx-package  7>; 

customerNamePkgDef inition  BEHAVIOUR 

DEFINED  AS 

IThe  Customer  Name  attribute  identifies  any  customer  that  is  a  user  of  the  resource.!; 
customerNamePkgBehaviour  BEHAVIOUR 
DEFINED  AS 

!If  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  customerName  attribute  changes  value.!; 

A.4.2.8  Function  List  Package 

functionListPkg  PACKAGE 

BEHAVI OUR  f unct i onL  i  stPkgDef  i ni  t  i on, 
f unct  i  onL  i  stPkgBehavi  our; 

ATTRIBUTES  functionList  PERMITTED  VALUES  SYNTAX- 1 .AnyNamesRange  GET-REPLACE  ADD-REMOVE; 

REGISTERED  AS  Cx-package  8>; 

f unct  i  onL  i  stPkgDef  i  ni  t  i  on   BEHAVI OUR 

DEFINED  AS 

IThe  functionList  attribute  identifies  those  functions    provided  by  this  resource.!; 
f unct  i  onL  i  stPkgBehavi  our  BEHAVIOUR 
DEFINED  AS 


45 


PART  18:  Network  Management 


December  1992  (Stable) 


I  If  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  functionList  attribute  changes  value.!; 

A.4.2.9  Function  Name  Package 

functionNamePkg  PACKAGE 

BEHAVI OUR  f unc t i onNamePkgDef  i ni  t i on, 
f unct i onNamePkgBehavi our; 

ATTRIBUTES  functionName  PERMITTED  VALUES  SYNTAX- 1 .AnyNameRange  GET-REPLACE; 

REGISTERED  AS  {x-package  9>; 

funct i onNamePkgDef i nit  ion  BEHAVICXJR 

DEFINED  AS 

!The  functionName  attribute  identifies  the  function  provided  by  this  resource. I; 
funct i onNamePkgBehavi our  BEHAVIOUR 
DEFINED  AS 

!If  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  functionName  attribute  changes  value.!; 

A.4.2.10  Incoming  Protocol  Error  Package 

incomingProtocolErrorPkg  PACKAGE 

BEHAV I OUR    i  ncomi  ngProtocol E  r rorPkgDef  i  ni  t  i  on, 
i ncomi ngProtocolE r rorPkgBehavi our ; 

ATTRIBUTES 

"Rec.  X.721  j  ISO/IEC  10165-2  :  1992": incomingProtocolErrorCounter 

PERMITTED  VALUES  SYNTAX -1. I nteger32  GET; 

REGISTERED  AS    Cx-package  10>; 


i  ncomi  ngProt oco I E  r rorPkgDef  i  n  i  t  i  on   BE  HAV I OUR 
DEFINED  AS 

IThis  package  reflects  the  capability  of  the  underlying  resource  to  count  the  number  of  incoming 
protocol  errors  detected.!; 


incomingProtocolErrorPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

<If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  incomingProtocolErrorCounter  attribute  wraps.!; 

A.4.2.11  Location  Pointer  Package 

locationPointerPkg  PACKAGE 

BEHAVIOUR     locationPointerPkgDef inition, 
I ocat  i  onPoi  nterPkgBehavi  our; 

ATTRIBUTES 

locationPointer  GET-REPLACE; 
REGISTERED  AS         {x-package  11>; 
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locationPointerPkgDef inition  BEHAVIOUR 
DEFINED  AS 

IThis  package  provides  managed  object  instance  information  for  a  location  (e.g.,  Hilo  Hawaii  USA). I; 


I ocat  i onPoi nterPkgBehav i  our  BEHAV I OUR 
DEFINED  AS 

•If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  Location  Pointer  attribute  changes  value.!; 


A.4.2.12  Manufacturer  List  Package 

manufacturerListPkg  PACKAGE 

BEHAVIOUR     manuf acturerL  i  stPkgDef  i  ni  t  i  on, 
manufacturerListPkgBehaviour; 

ATTRIBUTES 

manufacturerList    PERMITTED  VALUES  SYNTAX- 1 .AnyNamesRange  GET-REPLACE  AOD-REMOVE; 
REGISTERED  AS  {x-package  12>; 


manuf acturerL  i  stPkgDef  i  ni  t  i  on  BEHAV I  OUR 
DEFINED  AS 

IThis  package  indicates  information  about  the  manufacturer(s)  that  manufactured  the  underlying 
resource! ; 


manufacturerListPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

!If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  ManufacturerList  attribute  changes  value.!; 


A.4.2.13  Manufacturer  Name  Package 

manufacturerNamePkg  PACKAGE 

BE  HAVI OUR     manuf ac  turerNamePkgDef  i  n  i  t  i  on , 
manuf acturerNamePkgBehavi our; 

ATTRIBUTES 

manuf acturerName    PERMITTED  VALUES  SYNTAX- 1 .AnyNameRange  GET-REPLACE; 
REGISTERED  AS  {x-package  13>; 


manuf acturerNamePkgDef  i  ni  t  i on  BEHAV I OJR 
DEFINED  AS 

!This  package  indicates  information  about  the  manufacturer  that  manufactured  the  underlying 
resource! ; 


manuf acturerNamePkgBehavi  our  BE  HAV I OUR 
DEFINED  AS 

!If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  ManufacturerName  attribute  changes  value.!; 
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A.4.2.14  Max  PDU  Size  IV  Package 


maxPDUSizelVPkg  PACKAGE 

BEHAVIOUR  maxPOUSizelVPkgDefinition, 
maxPDUS i ze I VPkgBeha V i our ; 

ATTRIBUTES 

maxPDUSize    PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET-REPLACE; 
REGISTERED  AS  {x-package  U>; 


maxPDUS i zel VPkgDef i ni t i on  BE HAV I OUR 
DEFINED  AS 

IThis  package  provides  the  initial  value  for  the  maximum  length  of  a  PDU  that  can  be  supported  by 
the  local  layer  entity.!; 

maxPDUSizelVPkgBehaviour  BEHAVIOUR 

DEFINED  AS 

■The  Maximum  TPDU  Size  attribute  provides  the  initial  value  to  be  used  by  newly- instantiated 
subordinate  Transport  Connection  managed  object  instances  for  the  maximum  TPDU  size  to  be  supported 
on  that  connection.!; 


A.4.2.15  Max  Retransmissions  Pacltage 


maxRetransmissionsPkg  PACKAGE 

BEHAVIOUR    maxRet ransmi  ssi  onsPkgDef  i  ni  t  i  on, 
maxRet  ransmi  ssi  onsPkgBehavi  our; 

ATTRIBUTES 

maxRetransmissions    PERMITTED  VALUES  SYNTAX -1. I nteger32  GET; 
REGISTERED  AS    <x-package  15>; 


maxRetransmissionsPkgDef inition  BEHAVIOUR 
DEFINED  AS 

!This  package  reflects  the  capability  of  the  underlying  transport  protocol  resource  to  count  the 
maximum  number  of  times  a  TPDU  is  to  be  retransmitted  before  the  transport  connection  is  aborted.!; 


maxRet ransmi ssi onsPkgBehavi our  BEHAVIOUR 
DEFINED  AS 

!When  a  new  Transport  Connection  instance  is  created  containing  this  package,  any  "DPI  Library  Vol. 
2  :  1992":transportConnectionRetransmissionIVM0  instance  with  the  same  superior  may  be  used  to 
provide  initial  attribute  values  for  the  new  instance.!; 

A.4.2.16  Memory  Size  Package 

memorySizePkg  PACKAGE 

BEHAVIOUR  memorySizePkgDef inition, 

memorySizePkgBehaviour; 
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ATTRIBUTES     menwrySize     PERMITTED  VALUES  SYNTAX- 1 .MemorySizeRange  GET; 
REGISTERED  AS  Cx-package  16>; 
memorySizePkgDef inition  BEHAVIOUR 
DEFINED  AS 

!The  memorySize  attribute  indicates,  in  kilobytes,  the  amount  of  memory  available  to  a  Processing 
Entity  (irrespective  of  its  current  usage).!; 

memorySizePkgBehaviour  BEHAVIOUR 
DEFINED  AS 

!lf  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  memorySize  attribute  changes  value.!; 

A.4.2.17  Memory  Utilization  Package 

memoryUtilizationPkg  PACKAGE 

BEHAVICXJR      memoryUti lizationPkgBehaviour; 

ATTRIBUTES     memoryUti I izati on     PERMITTED  VALUES  SYNTAX- 1 .PercentageRange 

GET;  --    ackJed  in  response  to  Bull  comment 

REGISTERED  AS  <x-package  17>; 

memoryUt  i I i  zat  i  onPkgBehavi  our  BEHAVIOUR 

DEFINED  AS 

lEven  if  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  NOT  emitted  when  the  memoryUti I izati on  attribute  changes  value.!; 

A.4.2.18  Octets  Retransmitted  Package 

octetsRetransmittedPkg  PACICAGE 

BEHAVIOUR    octetsRetransmittedPkgDef inition, 
octetsRetransmi ttedPkgBehaviour; 

ATTRIBUTES 

"Rec.  X.721  j  ISO/IEC  10165-2  :  1992":octetsRetransmittedErrorCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET; 

REGISTERED  AS    <x-package  18>; 


octetsRetransmittedPkgDef inition  BEHAVIOUR 
DEFINED  AS 

iThis  package  reflects  the  capability  of  the  underlying  transport  protocol  resource  to  count  the 
number  of  octets  retransmitted.!; 


octetsRetransmi ttedPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

!If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  octetsRetransmi tted  attribute  wraps.!; 
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A.4.2.19  OMNIPoint  Network  List  Package 

opNetworkListPkg  PACKAGE 

BEHAVIOUR  opNetworkL 1 stPkgOef i ni t i on, 
0|3NetworkL  i  stPkgBehavi  our; 

ATTRIBUTES    opNetworkList    PERMITTED  VALUES  SYNTAX- 1 .AnyNamesRange  GET-REPLACE  AOD-REMOVE; 

REGISTERED  AS  <x-package  19>; 

opNetworkListPkgOefinition  BEHAVIOUR 

DEFINED  AS 

IThe  opNetworkList  attribute  indicates  what  networks  use  or  are  dependent  on  the  resource.l; 
opNetworkLi StPkgBehavi our  BEHAVIOUR 
DEFINED  AS 

ilf  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  opNetworkList  attribute  changes  value. I; 

A.4.2.20  OMNIPoint  Network  Name  Package 

opNetworkNamePkg  PACKAGE 

BEHAVIOUR  opNetworkNamePkgDef inition, 
opNetworkNamePkgBehaviour; 

ATTRIBUTES    opNetworkName    PERMITTED  VALUES  SYNTAX- 1 .AnyNameRange  GET-REPLACE; 

REGISTERED  AS  Cx-package  20>; 

opNetworkNamePkgDef inition  BEHAVIOUR 

DEFINED  AS 

IThe  opNetworkName  attribute  indicates  what  network  uses  or  is  dependent  on  the  resource.!; 
opNetworkNamePkgBehaviour  BEHAVIOUR 
DEFINED  AS 

ilf  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  opNetworkName  attribute  changes  value.!; 

A.4.2.21  OMNIPoint  Version  Package 

opVersionPkg   PACKAGE    --  refinement  of  Rec.  M.3100  versionPackage 

BEHAVIOUR     opVersionPkgDef inition, 
opVers i onPkgBehavi our ; 

ATTRIBUTES 

"Rec.  M.3100  :  1992":version 

PERMITTED  VALUES  SYNTAX- 1 .GraphicString16  GET-REPLACE; 

REGISTERED  AS    Cx- package  21}; 
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opVers i onPkgDef  i ni  t  i on  BE HAVI OUR 
DEFINED  AS 

IThis  package  reflects  the  release  version  of  the  underlying  resource  as  an  attribute,  as  defined  by 
"Rec.  M.3100  :  1992".!; 


opVersionPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

!If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  Version  attribute  changes  value. <; 


A.4.2.22  Outgoing  Protocol  Error  Package 

outgoingProtocolErrorPkg  PACKAGE 

BEHAVIOUR    outgoingProtocolErrorPkgDef ini  tion, 
outgoingProtocolErro-PkgBehaviour; 

ATTRIBUTES 

"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":outgoingProtocolErrorCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET; 

REGISTERED  AS    {x-package  22>; 


OutgoingProtocolErrorPkgDef inition  BEHAVIOUR 
DEFINED  AS 

IThis  package  reflects  the  capability  of  the  underlying  resource  to  count  the  number  of  outgoing 
protocol  errors  detected.    Note  that  not  all  resources  have  this  capability.!; 


outgoingProtocolErrorPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

!If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  outgoingProtocolErrorCounter  attribute  wraps.!; 

A.4.2.23  PDUs  Retransmitted  Counter  Package 

pdusRetransmi  ttedCounterPkg  PACKAGE 

BEHAVIOUR    pdusRetransmittedCounterPkgDef inition, 
pdusRetransmi ttedCounterPkgBehavi our; 

ATTRIBUTES 

"Rec.  X.721  j  ISO/IEC  10165-2  :  1992":pdusRetransmi ttedErrorCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET; 

REGISTERED  AS    tx-package  23}; 


pdusRetransmittedCounterPkgDef inition  BEHAVIOUR 
DEFINED  AS 

IThis  package  reflects  the  capability  of  the  underlying  transport  protocol  resource  to  count  the 
number  of  PDUs  retransmitted.!; 
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pdusRetransmittedCounterPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

!If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  PDUsRetransmittedCounter  attribute  wraps.!; 


A.4.2.24  PDUs  Retransmitted  Threshold  Package 

pdusRetransmittedThresholdPkg  PACKAGE 

BEHAVIOUR    pdusRetransmittedThresholdPkgOef inition, 
pdusRet  ransmi  t  tedTh  resho IdPkgBehav  i  our ; 

ATTRIBUTES 

"Rec.  X.721  j  ISO/IEC  10165-2  :  1992":pdusRetransmittedErrorThreshold  GET-REPLACE; 
NOTIFICATIONS 

"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":conmunicationsAlarm; 
REGISTERED  AS    {x-package  24>; 


pdusRet ransmi  t tedThresholdPkgPef i ni  t i on   BEHAVI OUR 
DEFINED  AS 

IThis  package  reflects  the  capability  of  the  underlying  transport  protocol  resource  to  threshold  the 
number  of  PDUs  retransmitted.!; 


pdusRetransmittedThresholdPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

tuhen  a  new  Transport  Connection  instance  is  created  containing  this  package,  any  "0P1  Library  Vol. 
2  :  1992":transportConnectionRetransmissionIVM0  instance  with  the  same  superior  may  be  used  to 
provide  initial  attribute  values  for  the  new  instance. 

If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this  package, 
this  notification  is  emitted  when  the  pdusRetransmittedThreshold  attribute  changes  in  value.!; 


A.4.2.25  Peripheral  List  Package 

peripheralListPkg  PACKAGE 

BEHAVIOUR     peripheralListPkgDef inition, 
per  i  phera I L  i  s tPkgBehavi  our ; 

ATTRIBUTES 

peripheral  Li  St    PERMITTED  VALUES  SYNTAX- 1 .AnyNamesRange  GET-REPLACE  ADD-REMOVE; 
REGISTERED  AS         Cx-package  25>; 


per i phera I L  i  stPkgDef  i  ni  t  i  on  BEHAV I OUR 
DEFINED  AS 

■The  Peripheral  List  attribute  identifies  auxiliary  devices  that  are  used  by  the  resource  (e.g., 
disk  drives,  tape  drives,  printers),!; 


per i phera I L i stPkgBehavi our  BEHAVI OUR 
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DEFINED  AS 

I  If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  Peripheral  List  attribute  changes  value. I; 


A.4.2.26  Peripheral  Name  Package 

peripheralNamePkg  PACKAGE 

BEHAVIOUR     per  i  phera I NamePkgOef  i  ni  t  i  on, 
per i phera I NamePkgBehavi our ; 

ATTRIBUTES 

peri phera I Name   PERMITTED  VALUES  SYNTAX- 1 .AnyNameRange  GET-REPLACE; 
REGISTERED  AS         {x-package  26>; 


peripheralNamePkgDef inition  BEHAVICXJR 
DEFINED  AS 

!The  Peripheral  Name  attribute  identifies  an  auxiliary  device  that  is  used  by  the  resource  (e.g., 
disk  drive,  tape  drive,  printer).!; 


peripheralNamePkgBehaviour  BEHAVIOUR 
DEFINED  AS 

)If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  Peripheral  Name  attribute  changes  value. I; 


A.4.2.27  Processing  Entity  List  Package 

process ingEntityListPkg  PACKAGE 

BEHAV 1 OUR     process  i  ngEnt  i  tyL  i  stPkgDef  i  ni  t  i  on, 
process  i  ngEnt  i  tyL  i  stPkgBehavi  our ; 

ATTRIBUTES 

process i ngEnt i tyL i St    PERMITTED  VALUES  SYNTAX- 1 .AnyNamesRange  GET-REPLACE  ADD-REMOVE; 
REGISTERED  AS  {x-package  27}; 


process i  ngEnt  i  tyL  i  s tPkgDef  i n i  t  i  on  BE HAV I OUR 
DEFINED  AS 

IThe  Processing  Entity  List  attribute  identifies  the  processing  entities  which  may  be  used  by  the 
containing  object  instance  but  which  are  not  contained  in  it  (i.e.,  processing  entities  which  are 
shared  among  systems) . ! ; 


processingEnti tyL i StPkgBehavi our  BEHAVKXJR 
DEFINED  AS 

I  If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  Processing  Entity  List  attribute  changes  value. I; 


A.4.2.28  Processing  Entity  Name  Package 


53 


PART  18:  Network  Management 


process ingEntityNamePkg  PACKAGE 

BEHAVIOUR     process  i  ngEnt  i  tyNamePkgDef  i  ni  t  i  on, 
processingEntityNamePkgBehaviour; 

ATTRIBUTES 

process! ngEnt ityName    PERMITTED  VALUES  SYNTAX- 1 .AnyNameRange  GET-REPLACE; 
REGISTERED  AS  Cx-package  28>; 


process i  ngEnt  i  tyNamePkgDef  i  ni  t  i on  BE HAV I OUR 
DEFINED  AS 

!The  Processing  Entity  Name  attribute  identifies  the  processing  entity  which  may  be  used  by  the 
containing  object  instance  but  which  is  not  contained  in  it  (i.e.,  processing  entities  which  are 
shared  among  systems).!; 


process i ngEnt  i  tyNamePkgBehav i  our  BEHAV I OUR 
DEFINED  AS 

■If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using 
package,  this  notification  is  emitted  when  the  Processing  Entity  Name  attribute  changes 


A.4.2.29  Product  Label  Package 


productLabelPkg  PACKAGE 

BEHAVIOUR     productLabelPkgDef inition, 
pr oduc  t  L  abe I PkgBehav  i  our ; 

ATTRIBUTES 

productLabel    PERMITTED  VALUES  SYNTAX-1 .GraphicString32  GET-REPLACE; 
REGISTERED  AS  (x- package  29>; 


productLabelPkgDef inition  BEHAVIOUR 
DEFINED  AS 

■This  package  allows  the  product  number  or  identifying  string  (e.g.,  model  number)  of  the  underlying 
resource  to  be  reflected  as  an  attribute.!;  , 


productLabelPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

!If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  Product  Label  attribute  changes  value.!; 


A.4.2.30  Retransmission  Time  Package 


retransmissionTimePkg  PACKAGE 

BEHAVIOUR    ret  ransmi  ss  i  onT  i  mePkgDef  i  ni  t  i  on, 
retransmissionTimePkgBehaviour; 


December  1992  (Stable) 


this 

value. ! ; 
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ATTRIBUTES 

retransmissionTime  PERMITTED  VALUES  SYNTAX- 1. I ntegerSZ  GET; 
REGISTERED  AS    <x-package  30>; 
ret  ransmi  ss  i  onT  i  mePkgOef  i  n  i  t  i  on   BE  KAV I OUR 
DEFINED  AS 

IThis  package  reflects  the  capability  of  the  underlying  transport  protocol  resource  to  present  its 
current  retransmission  timer  value  as  an  attribute.!; 


ret  ransffli  ss  i  onT  i  mePkgBehav  i  our   BE  HAV I OUR 
DEFINED  AS 

iUhen  a  new  Transport  Connection  instance  is  created  containing  this  package,  the  initial  value  of 

this  attribute  may  be  provided  by  the  retransmissionTimerlnitialValue  attribute  (if  present  in  the 
new  managed  object  instance).!; 


A.4.2.31  Retransmission  Timer  Initial  Value  Package 


ret  ransffli  ss  i  onT  imerlnitialVal uePkg  PACKAGE 

BE HAV I OUR    ret  ransmi  ss  i  onT  i  mer I n  i  t  i  a I Va I uePkgOef  i  n  i  t  i  on , 
ret r ansmi ss i onT i mer I n i t i a I Va I uePkgBehav i our ; 

ATTRIBUTES 

retransmissionTimerlnitialValue  PERMITTED  VALUES  SYNTAX- 1. I nteger32  GET; 
REGISTERED  AS    <x-package  31>; 

retransmissionTimerlnitialValuePkgDef inition  BEHAVIOUR 
DEFINED  AS 

IThis  package  reflects  the  capability  of  the  underlying  transport  protocol  resource  to  present  its 
initial  retransmission  timer  value  as  an  attrilsute. ! ; 


ret  ransmi  ss  i  onT  i  mer I ni  t  i  a I Va I uePkgBehav  i  our   BEHAV I OUR 
DEFINED  AS 

IUhen  a  new  Transport  Connection  instance  is  created  containing  this  package,  any  "OPI  Library  Vol. 
2  :  1992":transportConnectionRetransmissionIVM0  instance  with  the  same  superior  may  be  used  to 
provide  initial  attribute  values  for  the  new  instance.!; 


A.4.2.32  Serial  Number  Package 


serialNumberPkg  PACKAGE 

BEHAVIOUR     serialNumberPkgDef inition. 

ser  i  a  I  NuniierPkgBehavi  our ; 

ATTRIBUTES 

serialNumber     PERMITTED  VALUES  SYNTAX-1 .GraphicString32  GET-REPLACE; 
REGISTERED  AS         {x-package  32>; 
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serialNunfcerPkgDefinition  BEHAVIOUR 
DEFINED  AS 

■This  package  allows  the  serial  number  of  the  underlying  resource  to  be  reflected  as  an  attribute.!; 

serialNumberPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

!If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  Serial  Number  attribute  changes  value.!; 

A.4.2.33  Service  List  Package 

serviceListPkg  PACKAGE 

BEHAVIOUR  servi ceL  i  stPkgDef  i ni  t i on, 
serviceListPkgBehaviour; 

ATTRIBUTES     serviceList     PERMITTED  VALUES  SYNTAX- 1 .AnyNamesRange  GET-REPLACE  ADD-REMOVE; 

REGISTERED  AS  <x-package  33>; 

servi  ceL  i  stPkgDef  i  ni  t  i  on   BEHAVI OUR 

DEFINED  AS 

■Service  List  attribute  identifies  any  services  that    are  supported  by  the  resource.!; 
serviceListPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

ilf  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  serviceList  attribute  changes  value.!; 

A.4.2.34  Service  Name  Package 

servi ceNamePkg  PACKAGE 

BEHAVIOUR  servi ceNamePkgDefi nit  ion, 
servi ceNamePkgBehavi our ; 

ATTRIBUTES     serviceName     PERMITTED  VALUES  SYNTAX- 1 .AnyNameRange  GET-REPLACE; 

REGISTERED  AS  <x-package  34>; 

serviceNamePkgDef inition  BEHAVIOUR 

DEFINED  AS 

iService  Name  attribute  identifies  any  service  that  is  supported  by  the  resource.!; 
serviceNamePkgBehaviour  BEHAVIOUR 
DEFINED  AS 

■If  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  serviceName  attribute  changes  value.!; 

A.4.2.35  Software  List  Package 

softwareListPkg  PACKAGE 

BEHAVIOUR  softwareLi StPkgDef inition. 
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sof tuareL  i  stPkgBehavi  our; 
ATTRIBUTES    softwareList  PERMITTED  VALUES  SYNTAX- 1 .AnyNamesRange  GET-REPLACE  AOD-REMOVE; 
REGISTERED  AS  {x-package  35>; 
softwareListPkgDefinition  BEHAVIOUR 
DEFINED  AS 

IThe  Software  List  attribute  identifies  those  software  components  that  run  on  or  are  considered  part 
of  the  resource.!; 

softwareLi StPkgBehavi our  BEHAVIOUR 

DEFINED  AS 

I  If  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  softwareList  attribute  changes  value.!; 

A.4.2.36  Software  Name  Package 

softwareNamePkg  PACKAGE 

BEHAVIOUR  sof twareNamePkgDef  i ni  t  i  on, 
sof twareNamePkgBehaviour; 

ATTRIBUTES    softwareName  PERMITTED  VALUES  SYNTAX- 1 .AnyNameRange  GET-REPLACE; 

REGISTERED  AS  Cx-package  36>; 

sof  twareNamePkgDef  i  ni  t  i  on   BE  HAV I OUR 

DEFINED  AS 

!The  Software  Name  attribute  identifies  the  software  component  that  runs  on  or  are  considered  part 
of  the  resource. ! ; 

sof twareNamePkgBehaviour  BEHAVIOUR 

DEFINED  AS 

!If  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  softwareName  attribute  changes  value.!; 

A.4.2.37  System  Time  Package 

systemTimePkg  PACKAGE 

BEHAVIOUR     systemTimePkgDef inition, 
sys temT  i  mePkgBehav  i  our ; 

ATTRIBUTES 

systemTime   PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET; 
REGISTERED  AS  Cx-package  37>; 

systemTimePkgDef inition  BEHAVIOUR 
DEFINED  AS 

!This  package  records  the  current  time  clocked  by  the  resource.!; 
systemTimePkgBehaviour  BEHAVIOUR 
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DEFINED  AS 

!The  attribute  contained  in  this  package  is  never  the  subject  of  an  attribute  value  change 
notification.    Even  if  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class 
using  this  package,  this  notification  is  NOT  emitted  when  the  systemTime  attribute  changes  value. I; 


A.4.2.38  Type  Text  Package 


typeTextPkg  PACKAGE 

BEHAVIOUR  typeTextPkgDefinition, 
typeTextPkgBehaviour; 

ATTRIBUTES 

typeText     PERMITTED  VALUES  SYNTAX- 1 .Graph icString32  GET-REPLACE; 
REGISTERED  AS  Cx-package  38>; 


typeTextPkgDefinition  BEHAVIOUR 
DEFINED  AS 

IThis  package  serves  to  supplement  and  refine  individual  managed  object  class  attributes!; 


typeTextPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

■If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  Type  Text  attribute  changes  value.!; 


A.4.2.39  Up  Time  Package 

upTimePkg  PACKAGE 

BEHAVIOUR     upTimePkgDef inition, 
upT i mePkgBehav i our ; 

ATTRIBUTES 

upTime    PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET; 
REGISTERED  AS  {x-package  39>; 


upTimePkgDef inition  BEHAVIOUR 
DEFINED  AS 

■This  package  records  the  elapsed  time  during  which  the  underlying  resource  has  been  enabled.!; 


upTi mePkgBehav i our  BEHAVIOUR 
DEFINED  AS 

■The  attribute  contained  in  this  package  is  never  the  subject  of  an  attribute  value  change 
notification.    Even  if  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class 
using  this  package,  this  notification  is  NOT  emitted  when  the  upTime  attribute  changes  value.!; 
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A.4.2.40  Usage  State  Package 


usageStatePkg  PACKAGE 

BEHAVIOUR  usageStatePkgDefinition, 
usageStatePkgBehavi  our ; 

ATTRIBUTES 

"Rec.  X.721  j  ISO/IEC  10165-2  :  1992":usageState  GET; 

ATTRIBUTE  GROUPS 

••Rec.  X.721  j  ISO/IEC  10165-2  :  1992'':state 

"Rec.  X.721  I  ISO/IEC  10165-2  :  1992*':u8ageState; 

REGISTERED  AS  {x-package  40>; 


usageStatePkgOefinition  BEHAVIOUR 
DEFINED  AS 

IThis  package  specifies  the  Usage  State  of  the  mderlying  resource,  to  be  included  in  resources 
which  are  able  to  detect  whether  or  not  they  are  currently  in  use.!; 


usageStatePkgBehaviour  BEHAVIOUR 
DEFINED  AS 

I  If  the  stateChange  notification  is  defined  for  the  managed  object  class  using  this  package,  this 
notification  is  emitted  when  the  usageState  attribute  changes  value. I; 


A.4.2.41  Vendor  Ust  Package 

vendorListPkg  PACKAGE 

BEHAVIOUR  vendorListPkgOefinition, 
vendorL i stPkgBehavi our; 

ATTRIBUTES    vendorList  PERMITTED  VALUES  SYNTAX- 1 .AnyNamesRange  GET-REPLACE  ADD-REMOVE; 

REGISTERED  AS  {x-package  41>; 


vendorListPkgDefinition  BEHAVIOUR 
DEFINED  AS 

IThe  Vendor  List  attribute  identifies  the  organization(s)  from  which  the  resource  was  obtained 
(e.g.,  purchased,    leased,  etc.}!; 

vendorL i StPkgBehavi our  BEHAVIOUR 

DEFINED  AS 

!If  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  vendorList  attribute  changes  value.!; 


A.4.3  Name  Bindings 


A.4.3.1  Computer  System  Name  Bindings 
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computerSystem- system  NAME  BINDING 

SUBORDINATE  OBJECT  CLASS    computerSystem  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS  "Rec.  X.721  j  ISO/IEC  10165-2  :  1992": system; 
WITH  ATTRIBUTE  conputerSystemld; 

CREATE    UITH-REFERENCE-OBJECT,  WITH-AUTOMATIC- INSTANCE-NAMING; 

DELETE  ONLY-IF-NO-CONTAINEO-OBJECTS; 

REGISTERED  AS  {x-nameBinding  1>; 


computerSystem- opNetwork  NAME  BINDING 

SUBORDINATE  OBJECT  CLASS    computerSystem  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS        opNetuork  AND  SUBCLASSES; 
WITH  ATTRIBUTE  computerSystemId; 

CREATE    WITH-REFERENCE-OBJECT,  WITH-AUTOMATIC- INSTANCE-NAMING; 

DELETE  ONLY-IF-NO-CONTAINED-OBJECTS; 

REGISTERED  AS  <x-nameBinding  2>; 


computerSystem- computerSystem       NAME  BINDING 

SUBORDINATE  OBJECT  CLASS    computerSystem  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS        computerSystem  AND  SUBCLASSES; 
WITH  ATTRIBUTE  computerSystemId; 

CREATE    WITH-REFERENCE-OBJECT,  WITH-AUTOMATIC- INSTANCE-NAMING; 

DELETE    ONLY- I F-NO-CONTAINED-OBJECTS; 

REGISTERED  AS  Cx-nameBinding  3); 

A.4.3.2  CO  Transport  Protocol  Layer  Entity  Name  Bindings 

coTransportProtocolLayerEntity-computerSystem    NAME  BINDING 

SUBORDINATE  OBJECT  CLASS  coTransportProtocolLayerEntity  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS  computerSystem  AND  SUBCLASSES; 
WITH  ATTRIBUTE  coTransportProtocolLayerEntityld; 
REGISTERED  AS    tx-nameBinding  4>; 

coTransportProtocolLayerEntity-system    NAME  BINDING 

SUBORDINATE  OBJECT  CLASS  coTransportProtocolLayerEntity  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS 

"Rec.  X.721  j  ISO/IEC  10165-2  :  1992":  system  AND  SUBCLASSES; 
WITH  ATTRIBUTE  coTransportProtocolLayerEntityld; 
REGISTERED  AS    {x-nameBinding  5>; 

coTransportProtocolLayerEnti ty-opEquipment    NAME  BINDING 

SUBORDINATE  OBJECT  CLASS  coTransportProtocolLayerEntity  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS  opEquipment  AND  SUBCLASSES; 
WITH  ATTRIBUTE  coTransportProtocolLayerEnti tyld; 
REGISTERED  AS    {x-nameBinding  6>; 


A.4.3.3  CL  Networl<  Protocol  Layer  Entity  Name  Bindings 

clNetworkProtocolLayerEntity-computerSystem    NAME  BINDING 

SUBORDINATE  OBJECT  CLASS  clNetworkProtocolLayerEntity  AND  SUBCLASSES; 
NAMED  BY 
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SUPERIOR  OBJECT  CLASS  computerSystem  AND  SUBCLASSES; 
WITH  ATTRIBUTE  clNetuorkProtocolLayerEntityld; 
REGISTERED  AS    <x-nameBinding  7>; 

clNetuorkProtocolLayerEntity-system   NAME  BINDING 

SUBORDINATE  OBJECT  CLASS  clNetuorkProtocolLayerEntity  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS 

"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":  system  AND  SUBCLASSES; 
WITH  ATTRIBUTE  clNetworkProtocolLayerEntityld; 
REGISTERED  AS    {x-nameBinding  8>; 

clNetworkProtocolLayerEntityopEquipment    NAME  BINDING 

SUBORDINATE  OBJECT  CLASS  clNetuorkProtocolLayerEntity  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS  opEquipment  AND  SUBCLASSES; 
WITH  ATTRIBUTE  ClNetworkProtocolLayerEntityld; 
REGISTERED  AS    Cx-nameBinding  9>; 

A.4.3.4  OMNIPoint  Equipment  Name  Bindings 

opEquipment-computerSystem  NAME  BINDING 

SUBORDINATE  OBJECT  CLASS    opEquipment  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS    computerSystem  AND  SUBCLASSES; 
WITH  ATTRIBUTE    "Rec.  M.3100  :  1992":equipmentld; 

CREATE    WITH-REFERENCE-OBJECT,  WITH-AUTOMATIC- INSTANCE-NAMING; 

DELETE  ONLY-IF-NO-CONTAINEO-OBJECTS; 

REGISTERED  AS  <x-nameBinding  10}; 

opEquipment -system  NAME  BINDING 

SUBORDINATE  OBJECT  CLASS    opEquipment  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS    "Rec.  X.721  |  ISO/IEC  10165-2  :  1992":system; 
WITH  ATTRIBUTE    "Rec.  M.3100  :  1992": equipment  Id; 

CREATE    WITH-REFERENCE-OBJECT,  WITH-AUTOMATIC- INSTANCE-NAMING; 

DELETE    ONLY- I F-NO-CONTAINED-OBJECTS; 

REGISTERED  AS  Cx-nameBinding  11>; 

opEquipment -equipment  NAME  BINDING 

SUBORDINATE  OBJECT  CLASS  opEquipment  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS    "Rec.  M.3100  :  1992": equipment  AND  SUBCLASSES; 
WITH  ATTRIBUTE    "Rec.  M.3100  :  1992":equipmentld; 

CREATE    WITH-REFERENCE-OBJECT,  WITH-AUTOMATIC- INSTANCE-NAMING; 

DELETE    ONLY- I F-NO-CONTAINED-OBJECTS; 

REGISTERED  AS  Cx-nameBinding  12>; 

opEquipment -opNetwork  NAME  BINDING 

SUBORDINATE  OBJECT  CLASS    opEquipment  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS        opNetwork  AND  SUBCLASSES; 
WITH  ATTRIBUTE    "Rec.  M.3100  :  1992":equipmentld; 

CREATE    WITH-REFERENCE-OBJECT,  WITH-AUTOMATIC- INSTANCE-NAMING; 

DELETE    ONLY- I F-NO-CONTAINED-OBJECTS; 

REGISTERED  AS  Cx-nameBinding  13>; 

A.4.3.5  OMNIPoint  Networit  Name  Bindings 
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"  The  following  name  bindings  are  defined,  in  addition  to  those 

--  inherited  from  Rec.  M.3100  Network  (which  do  not  include  CREATE/DELETE): 

network-opNetwork-1  NAME  BINDING 

SUBORDINATE  OBJECT  CLASS    opNetwork  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS    "Rec.  M.3100  :  1992":network  AND  SUBCLASSES; 
WITH  ATTRIBUTE    "Rec.  M.3100  :  1992": network  Id; 

CREATE    UITH-REFERENCE-OBJECT,  UITH-AUTOMATIC-INSTANCE-NAMING; 

DELETE    ONLY- I F-NO-CONTAINED-OBJECTS; 

REGISTERED  AS  Cx-nameBinding  14>; 


network-opNetwork-2         NAME  BINDING 

SUBORDINATE  OBJECT  CLASS    opNetwork  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS  "Rec.  M.3100  :  1992":network  AND  SUBCLASSES; 
WITH  ATTRIBUTE  networklitle; 

CREATE    UITH-REFERENCE-OBJECT.  UITH-AUTOMATIC-INSTANCE-NAMING; 

DELETE    ONLY- I F-NO-CONTAINED-OBJECTS; 

REGISTERED  AS  Cx-nameBinding  15>; 


opNetwork- root  NAME  BINDING 

SUBORDINATE  OBJECT  CLASS    opNetwork  AND  SUBCLASSES; 

NAMED  BY  SUPERIOR  OBJECT  CLASS  "Rec.  X.660  |  ISO/IEC  9834-1  :  1992":root; 
WITH  ATTRIBUTE  networkTitle; 

CREATE    UITH-REFERENCE-OBJECT.  UITH-AUTOMATIC-INSTANCE-NAMING; 

DELETE    ONLY- I F-NO-CONTAINED-OBJECTS; 

REGISTERED  AS  <x-naineBinding  16>; 


A.4.3.6  Processing  Entity  Name  Bindings 

--  processingEntity-opEquipment  NAME  BINDING 
--  processingEntity-computerSystem  NAME  BINDING 

--  both  inherited  from  opEquipment,  no  additional  bindings  required. 


A.4.3.7  Transport  Connection  Name  Bindings 

transportConnection-coTransportProtocolLayerEntity   NAME  BINDING 

SUBORDINATE  OBJECT  CLASS  transportConnection  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS  coTransportProtocolLayerEnti ty  AND  SUBCLASSES; 
UITH  ATTRIBUTE  transportConnectionld; 
BE  HAV I OUR  t  ranspor t Connec  t  i  onNBBehav  i  our ; 
DELETE    DELETES-CONTAI NED-OBJECTS; 
REGISTERED  AS    {x-nameBinding  17>; 


t  ranspor tConnect  i  onNBBehav  i  our  BE  HAV I OUR 
DEFINED  AS 

(The  expected  real  effect  of  the  DELETE  operation  when  applied  to  an  instance  of  the  transport 
connection  managed  object  class  is  that  the  underlying  transport  connection  resource  is  aborted.!; 
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A.4.4  Attributes 

A.4.4.1  Active  Connections 

act iveConnect ions  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX- 1 . IntegerBase; 
MATCHES  FOR      EQUALITY,  ORDERING; 
BEHAVIOUR    act iveConnect ionsBehavi our; 

REGISTERED  AS        tx-attribute  1); 

ac t  i  veConnec  t  i  onsBeh  a v  i  ou  r     BE  HAV I OUR 

DEFINED  AS 

!The  act iveConnect ions  attribute  specifies  the  number  of  currently  active  transport  connections 
(i.e.,  the  number  of  transport  connections  which  are  in  the  open  state  [as  defined  for  the 
underlying  protocol  machine],  updated  upon  each  connection  establishment  and  release).!; 


A.4.4.2  Addressing  Size 

address ingSize  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX-1 .AddressingSizeBase; 

MATCHES  FOR  EQUALITY,  ORDERING; 

BE  HAV I  OUR    address  i  ngS  i  zeBehav  i  our ; 

REGISTERED  AS  Cx-attribute  2>; 

address ingSizeBehavi our  BEHAVIOUR 

DEFINED  AS 

!The  Addressing  Size  attribute  indicates  the  number  of  bits  which  represent  an  address  to  the 
Processing  Entity's  central  processing  unit  (CPU).!; 


A.A.4.3  Checksun  PDUs  Discarded  Counter 
checksumPDUsD  i  scardedCounter     ATTR I  BUTE 
DERIVED  FROM 

"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":  counter; 
BEHAVIOUR    ChecksumPDUsD iscardedCounterBehavi our; 

REGISTERED  AS        <x-attribute  3>; 

ChecksumPDUsD iscardedCounterBehavi our  BEHAVIOUR 

DEFINED  AS 

!The  attribute  specifies  the  number  of  well-formed  PDUs  rejected  by  the  peer  entity  due  to  a 
checksum  error. ! ; 

A.4.4.4  Computer  System  Id 

computerSystemId  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX-1 .GraphicStringBase; 
MATCHES  FOR    EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  computerSystemldBehaviour; 
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REGISTERED  AS        Cx-attribute  4}; 
computerSystemldBehaviour  BEHAVIOUR 
DEFINED  AS 

■The  cofnputerSystemId  attribute  is  the  distinguishing  attribute  for  the  computerSystem  managed 
object  class.!; 

A.4.4.5  CL  Network  Protocol  Layer  Entity  Id 

clNetworkProtocolLayerEntityld  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .GraphicStringBase; 

MATCHES  FOR    EQUALITY,  SUBSTRINGS; 

BEHAVIOUR  clNetuorkProtocolLayerEntityldBehaviour; 

REGISTERED  AS        {x-attribute  5}; 

clNetworkProtocolLayerEntityldBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  ClNetworkProtocolLayerEntityld  attribute  is  the  distinguishing  attribute  for  the 
clNetworkProtocolLayerEnti ty  managed  object  class.!; 

A.4.4.6  CO  Transport  Protocol  Layer  Entity  Id 

coTransportProtocolLayerEnti tyld  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX-1 .GraphicStringBase; 

MATCHES  FOR    EQUALITY,  SUBSTRINGS; 

BEHAVIOUR    CoTransportProtocolLayerEnti tyldBehaviour; 

REGISTERED  AS        <x-attribute  6}; 

CoTransportProtocolLayerEnti tyldBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  coTransportProtocolLayerEntityld  attribute  is  the  distinguishing  attribute  for  the 
coTransportProtocolLayerEntity  managed  object  class.!; 

A.4.4.7  Contact  List 

contactList  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  SYNTAX- 1 .AnyNamesBase; 
MATCHES  FOR  SET -COMPARISON,  SET- INTERSECTION; 
BEHAVIOUR    contact ListBehavi our; 

REGISTERED  AS  Cx-attribute  7}; 

contactListBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  Contact  List  attribute  provides  managed  object  instance  information  for  one  or  more  contacts. 
The  following  object  classes  (or  any  of  their  subclasses  or  allomorphic  classes)  are  valid  as 
contacts:  "OPI  Library  Vol.  4":Contact. 

The  SET -COMPARISON  and/or  SET- INTERSECTION  matching  rules  may  not  be  supported  by  some  managed 
object  instances  which  include  this  attribute.!; 

A.4.4.8  Contact  Name 


64 


PART  18:  Network  Management 


December  1992  (Stable) 


contactName  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .AnyNameBase; 
HATCHES  FOR  EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  contactNameBehaviour; 

REGISTERED  AS  <x-attribute  8>; 

contactNameBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  Contact  Name  attribute  provides  information  for  one  person  or  organization  who  can  be 
contactacted  about  the  resource.!; 

A.4.4.9  CPU  Type 

cpuType  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX-1 .GraphicStringBase; 
HATCHES  FOR  EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  cpuTypeBehaviour; 

REGISTERED  AS  (x-attribute  9>; 

cpuTypeBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  Central  Processor  Unit  (CPU)  Type  attribute  indicates  the  type  of  central  processor  unit  found 
in  a  Processing  Entity.!; 

A.4.4.10  CPU  Utilization 

cpuUtilization  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX-1 . IntegerBase; 
HATCHES  FOR  EQUALITY,  ORDERING; 
BEHAVIOUR  cpuUtilizationBehaviour; 

REGISTERED  AS  <x-attribute  10>; 

cpuUtilizationBehaviour  BEHAVIOUR 

DEFINED  AS 

I  The  cpuUtilization  attribute  specifies,  as  a  percentage,  the  overall  utilization  of  all  central 
processor  units  found  in  a  processing  entity.    The  percentage  is  expressed  as  an  integer  with 
permissible  values  in  the  range  of  0  to  100.); 

A.4.4.11  Customer  List 

customerList  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  SYNTAX-1 .AnyNamesBase; 
HATCHES  FOR  SET-COHPARISON,  SET- INTERSECTION; 
BEHAVIOUR  customerListBehaviour; 

REGISTERED  AS  Cx-attribute  11>; 

customerListBehaviour  BEHAVIOUR 

DEFINED  AS 
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IThe  Customer  List  attribute  provides  managed  object  instance  information  about  one  or  more 
customers.    The  following  classes  (or  any  of  their  subclasses  or  allomorphic  classes)  are  valid  as 
customers:  "0P1  Library  Vol.  4":Customer. 

The  SET -COMPARISON  and/or  SET* INTERSECTION  matching  rules  may  not  be  supported  by  some  managed 
object  instances  which  include  this  attribute.!; 

A.4.4.12  Customer  Name 

customerName  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .AnyNameBase; 
MATCHES  FOR  EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  customerNameBehaviour; 

REGISTERED  AS  (x-attribute  12>; 

customerNameBehaviour  BEHAVIOUR 

DEFINED  AS 

■The  Customer  Name  attribute  provides  information  about  one  customer.!; 

A.4.4.13  Endianess 

endianess  ATTRIBUTE 

..      WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1  .Endianess; 
MATCHES  FOR  EQUALITY,  ORDERING; 
BEHAVIOUR  endianessBehaviour; 

REGISTERED  AS  Cx-attribute  13>; 

endianessBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  Endianess  attribute  indicates  the  bit  order  (big  endian,  little  endian)  used  by  the  Processing 
Entity's  central  processing  unit  (CPU).!; 


A. 4.4. 14  Function  List 

functionList  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  SYNTAX- 1 .AnyNamesBase; 
MATCHES  FOR  SET -COMPARISON,  SET- INTERSECTION; 
BEHAVIOUR  functionListBehaviour; 

REGISTERED  AS  (x-attribute  14); 

functionListBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  Function  List  attribute  provides  managed  object  instance  information  about  one  or  more 
functions.    The  following  managed  object  classes  (or  any  of  their  subclasses  or  allomorphic  classes) 
are  valid  as  functions:    "0P1  Library  Vol.  A":Function. 

The  SET -COMPARISON  and/or  SET- INTERSECTION  matching  rules  may  not  be  supported  by  some  managed 
object  instances  which  include  this  attribute.!; 

A.4.4.15  Function  Name 
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functionName  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .AnyNameBase; 
MATCHES  FOR  EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  functionNameBehaviour; 

REGISTERED  AS  (x-attribute  15>; 

functionNameBehaviour  BEHAVIOUR 

DEFINED  AS 

tThe  Function  Name  attribute  provides  information  about  one  function.!; 

A.4.4.16  Inactivity  Time 

inactivityTime  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX      SYNTAX- 1 .HundredthsOf Sec; 
MATCHES  FOR     EQUALITY,  ORDERING; 
BEHAVIOUR  inactivityTimeBehaviour; 

REGISTERED  AS         <x-attribute  16>; 

i  nac t  i  V  i  t yT  i  meBehav  i  our    BE  HAV I OUR 

DEFINED  AS 

■This  attribute  specifies  the  amount  of  time  (in  1/100ths  of  a  second)  that  the  transport  connection 
has  been  inactive.!; 

A.4.4.17  Inactivity  Timeout 

inactivityTimeout  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX- 1 .HundredthsOf Sec; 

MATCHES  FOR      EQUALITY,  ORDERING; 

BE  HAV  I  OUR    i  nac  t  i  v  i  t  yT  i  meout  Behav  i  our ; 

REGISTERED  AS         Cx-attribute  17>; 

inact  i  vi  tyT  imeoutBehavi  our  BEHAVIOUR 

DEFINED  AS 

■This  attribute  specifies  the  maximum  amount  of  time  (in  1/100ths  of  a  second)  that  the  transport 
connection  can  remain  enabled  when  there  is  no  activity  (i.e..  data  flow  )  on  it.    A  value  of  0  for 
this  attribute  indicates  that  an  inactivity  timeout  is  not  supported  on  the  transport  connection.!; 

A.4.4.18  Local  Network  Address 

localNetMorkAddress  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .Address; 
MATCHES  FOR       EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  localNetworkAddressBehaviour; 

REGISTERED  AS         <x-attribute  18>; 

localNetworkAddressBehaviour  BEHAVIOUR 

DEFINED  AS 

■The  localNetworkAddress  attribute  identifies  the  local  network  address  supported  by  a  network 
protocol  layer  entity  (e.g.,  local  IP  address  for  TCP  or  the  local  NSAP  address  for  OSI).!; 
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A.4.4.19  Local  Network  Addresses 


I oca I NetworkAddresses 


ATTRIBUTE 


WITH  ATTRIBUTE  SYNTAX       SYNTAX- 1 .NetworkAddresses; 
MATCHES  FOR      SET -COMPARISON,  SET -INTERSECT ION, - 
BE  HAV I OUR    I oca I Net wor kAddressesBehavi  our ; 


REGISTERED  AS 


<x-attribute  19>; 


localNetworkAddressesBehaviour  BEHAVIOUR 
DEFINED  AS 

IThe  I oca I NetworkAddresses  attribute  identifies  the  local  network  addresses  supported  by  a  network 
protocol  layer  entity  (e.g.,  local  IP  address  for  TCP  or  the  local  NSAP  address  for  OSI). 

Set  comparison  and/or  set  intersection  matching  rules  may  not  be  supported  by  some  managed  object 
instances  which  include  this  attribute.!; 

A.4.4.20  Local  Transport  Addresses 

localTransportAddresses  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX- 1 .TransportAddresses; 
MATCHES  FOR      SET -COMPARISON,  SET- INTERSECTION; 
BEHAVIOUR  localTransportAddressesBehaviour; 

REGISTERED  AS    {x-attribute  20>; 

I oca I T  ranspor t AddressesBehav  i  our     BE  HAV I OUR 

DEFINED  AS 

■The  localTransportAddresses  attribute  specifies  the  set  of  local  transport  addresses  (e.g,  local 
TSAP  identifiers)  that  a  connection  oriented  transport  protocol  layer  entity  provides  to  its  users. 
A  transport  address  consists  of  a  transport  connection  endpoint  and  a  network  address. 

Set  comparison  and/or  set  intersection  matching  rules  may  not  be  supported  by  some  managed  object 
instances  which  include  this  attribute.!; 

A.4.4.21  Local  Transport  Connection  Endpoint 

loca I T  ransportConnect  i  onEndpoi  nt  ATTR I  BUTE 


localTransportConnectionEndpointBehaviour  BEHAVIOUR 
DEFINED  AS 

!This  attribute  identifies  the  local  transport  connection  endpoint  (e.g.,  the  source  port  for  TCP  or 
the  local  t-selector  for  OSI  Transport  protocol).!; 

A.4.4.22  Location  Pointer 

locationPointer  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX-1 .Objectlnstance; 
MATCHES  FOR  EQUALITY; 


WITH  ATTRIBUTE  SYNTAX     SYNTAX- 1 .Address; 

MATCHES  FOR      EQUALITY,  SUBSTRINGS; 

BEHAVIOUR     localTransportConnect ionEndpointBehaviour; 


REGISTERED  AS 


€x-attribute  21}; 
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BEHAVIOUR  locationPointerBehaviour; 
REGISTERED  AS  <x-attribute  22>; 
locationPointerBehaviour  BEHAVIOUR 
DEFINED  AS 

IThe  Location  Pointer  attribute  provides  managed  object  instance  information  for  a  location  (e.g., 
Hilo  Hawaii  USA).  The  following  managed  object  classes  (or  any  of  their  subclasses  or  allonorphic 
classes)  are  valid  as  locations:    "0P1  Library  Vol.  4":Location.i; 

A.4.4.23  Manufacturer  List 

manufacturerList  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .AnyNamesBase; 

MATCHES  FOR    SUBSTRINGS,  SET -COMPARISON,  SET-INTERSECTION; 

BEHAVIOUR   manuf acturerL  i  stBehavi  our; 

REGISTERED  AS         {x-attribute  23>; 

manufacturerListBehaviour  BEHAVIOUR 

DEFINED  AS 

IThe  manufacturerList  attribute  indicates  information  about  the  manufacturer(s)  that  manufactured 
the  underlying  resource.    This  attribute  contains  object  instance  name(s)  for  "0P1  Library  Vol. 
4":manufacturer  (or  any  subclass  or  allomorphic  class). 

Set  comparison  and/or  set  intersection  matching  rules  may  not  be  supported  by  some  managed  object 
instances  which  include  this  attribute.!; 

A.4.4.24  Manufacturer  Name 

manuf acturerName  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .AnyNameBase; 
MATCHES  FOR    EQUALITY.  SUBSTRINGS; 
BEHAVIOUR    manuf acturerNameBehavi our; 

REGISTERED  AS         <x-attribute  24>; 

manuf acturerNameBehavi our  BEHAVICXIR 

DEFINED  AS 

IThe  manufacturerName  attribute  indicates  information  about  the  manufacturer(s)  that  manufactured 
the  underlying  resource.    This  attribute  contains  descriptive  text. I; 

A.4.4.25  Max  Connections 

maxConnections  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX- 1 . IntegerBase; 
MATCHES  FOR     EQUALITY,  ORDERING; 
BEHAVIOUR  maxCormectionsBehaviour; 

REGISTERED  AS        {x- attribute  25}; 

maxConnectionsBehaviour  BEHAVIOUR 

DEFINED  AS 
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IThe  maxConnections  attribute  specifies  the  maximum  number  of  simultaneously  active/open  transport 
connections  that  can  be  supported  by  the  transport  protocol  layer  entity.!; 

A.4.4.26  Max  PDU  Size 

maxPDUSize  ATTRIBUTE 

UITH  ATTRIBUTE  SYNTAX     SYNTAX- 1 . IntegerBase; 
MATCHES  FOR     EQUALITY,  ORDERING; 
BEHAVIOUR  maxPDUSizeBehaviour; 

REGISTERED  AS        <x-attribute  26>; 

maxPDUSizeBehaviour  BEHAVIOUR 

DEFINED  AS 

IThe  maxPDUSize  attribute  specifies  the  maximum  length  of  a  PDU  that  can  be  supported  by  the  local 
layer  entity.!; 

A.4.4.27  Max  Retransmissions 

maxRetransmissions  ATTRIBUTE 

UITH  ATTRIBUTE  SYNTAX     SYNTAX- 1 . IntegerBase; 
MATCHES  FOR      EQUALITY,  ORDERING; 
BEHAVI OUR    maxRet  ransmi  ss  i  onsBehavi  our ; 

REGISTERED  AS        <x-attribute  27>; 

maxRet  ransmi  ss  i  onsBehav i  our     BE HAV I OUR 

DEFINED  AS 

iThis  attribute  specifies  the  maximum  number  of  times  a  TPDU  is  to  be  retransmitted  before  the 
transport  connection  is  aborted.!; 

A.4.4.28  Memory  Size 

memorySize  ATTRIBUTE 

UITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .MemorySizeBase; 
MATCHES  FOR  EQUALITY,  ORDERING; 
BEHAVIOUR  memorySizeBehaviour; 

REGISTERED  AS  (x-attribute  28}; 

memorySizeBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  Memory  Size  attribute  indicates,  in  kilobytes,  the  amount  of  memory  available  to  a  Processing 
Entity  (irrespective  of  its  current  usage).!; 

A.4.4.29  Memory  Utilization 

memoryUtilization  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 . IntegerBase; 

MATCHES  FOR  EQUALITY,  ORDERING; 
BEHAVIOUR    memoryUti lizationBehaviour; 

REGISTERED  AS  <x-attribute  29>; 
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memryUtilizationBehaviour  BEHAVIOUR 
DEFINED  AS 

■The  memoryUti lization  attribute  specifies,  as  a  percentage,  the  overall  utilization  of  amount  of 
memory  available  to  a  processing  entity.    The  percentage  is  expressed  as  an  integer  with  permissible 
values  in  the  range  of  0  to  100. i; 

A.4.4.30  Network  Entity  Type 

networkEntityType  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX-1 .NetworkEntityType; 

MATCHES  FOR  EQUALITY; 

BEHAVIOUR  networkEntityTypeBehaviour; 

REGISTERED  AS  Cx-attribute  30>; 

networkEntityTypeBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  networkEntityType  attribute  indicates  the  type  of  the  network  protocol  layer  entity. I; 

A.4.4.31  Network  Title 

networkTitle  ATTRIBUTE 

DERIVED  FROM  "Rec.  X.721  |  ISO/IEC  10165-2  :  1992":systemTitle; 
BEHAVIOUR  networkTitleBehaviour; 

REGISTERED  AS  <x-attribute  31>; 

networkTitleBehaviour  BEHAVIOUR 

DEFINED  AS 

IThe  Network  Title  is  one  of  the  distinguishing  attribute  the  network  managed  object  class  for  use 
as  described  in  clause  6.3  of  [MIM]!; 

A.4.4.32  NPDU  Time  To  Live 

nPDUTimeToLive  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX-1 . IntegerBase; 
MATCHES  FOR      EQUALITY,  ORDERING; 
BEHAVI OUR    nPDUT  i  meToL  i  veBehavi  our; 

REGISTERED  AS  (x-attribute  32>; 

nPDUTimeToLi veBehavi our  BEHAVIOUR 

DEFINED  AS 

IThis  attribute  specifies  the  maximum  annount  of  time  (in  units  of  10  ms)  that  an  NPDU  can  exist  in 
the  network.    This  attribute  is  used  to  limit  the  lifetime  of  NPDUs  during  unstable  network 
situations.!; 

A.4.4.33  OMNIPoint  Equipment  List 

opEquipmentList  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  SYNTAX-1 .AnyNamesBase; 
MATCHES  FOR  SET -COMPARISON,  SET- INTERSECTION; 
BEHAVIOUR  opEquipmentListBehaviour; 
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REGISTERED  AS  {x-attribute  33>; 

opEqu  i  pment  L  i  s  t  Behav  i  our  BE  HA V I OUR 

DEFINED  AS 

IThe  OHNIPoint  Equipment  List  attribute  provides  managed  object  instance  information  about  one  or 
more  pieces  of  opEquipment.    The  following  classes  (or  any  of  their  subclasses  or  allomorphic 
classes)  are  valid  as  equipment:  OMNI  Point  Equipment. 

The  SET -COMPARISON  and/or  SET- INTERSECTION  matching  rules  may  not  be  supported  by  some  managed 
object  instances  which  include  this  attribute. I; 

A.4.4.34  OMNIPoint  Network  List 

opNetworkList  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  SYNTAX- 1 .AnyNamesBase; 
MATCHES  FOR  SET -COMPARISON,  SET- INTERSECTION; 
BEHAVIOUR  opNetworkListBehaviour; 

REGISTERED  AS  (x-attribute  3A}; 

opNetworkListBehaviour  BEHAVIOUR 

DEFINED  AS 

IThe  OMNIPoint  Network  List  attribute  shall  provide  managed  object  instance  information  about  a  set 
of  networks.    The  following  object  classes  (or  any  of  their  subclasses  or  allomorphic  classes)  are 
valid  as  networks:  OMNIPoint  Network. 

The  SET -COMPARISON  and/or  SET- INTERSECTION  matching  rules  may  not  be  supported  by  some  managed 
object  instances  which  include  this  attribute.!; 

A.4.4.35  OMNIPoint  Network  Name 

opNetworkName  ATTRIBUTE 

UITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .AnyNameBase; 
MATCHES  FOR  EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  opNetworkNameBehaviour; 

REGISTERED  AS  <x-attribute  35>; 

opNetworkNameBehaviour  BEHAVIOUR 

DEFINED  AS 

■The  OMNIPoint  Network  Name  attribute  shall  provide  information  about  a  network.!; 

A.4.4.36  Operating  System  Information 

oslnfo  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .Os I nfoBase; 

MATCHES  FOR  EQUALITY,  SET -COMPARISON,  SET- INTERSECTION; 

BEHAVIOUR  osInfoBehaviour; 

REGISTERED  AS  Cx-attribute  36>; 

osInfoBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  Operating  System  Information  attribute  specifies  the  names  and  releases  of  the  supported 
operating  systems. 
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The  SET -COMPARISON  and/or  SET- INTERSECTION  matching  rules  may  not  be  supported  by  some  managed 
object  instances  which  include  this  attribute.!; 

A.4.4.37  PDUs  Forwarded  Counter 

pdusForwardedCounter  ATTRIBUTE 

DERIVED  FROM  "Rec.  X.721  |  ISO/IEC  10165-2  :  1992":  counter; 
BEHAVIOUR  pdusForuardedCounterBehaviour; 

REGISTERED  AS        Cx-attribute  37}; 

pdusForwardedCounterBehaviour  BEHAVIOUR 

DEFINED  AS 

IThis  attribute  specifies  the  number  of  valid  incoming  PDUs  which  were  forwarded  (transmitted  as 
outgoing  PDUs)  to  another  destination.    This  attribute  does  not  count  incoming  PDUs  which  were 
delivered  to  a  local  service  user.!; 

A.4.4.38  PDUs  Reassembled  Ok  Counter 

pdusReasmbldOKCounter  ATTRIBUTE 

DERIVED  FROM  "Rec.  X.721  |  ISO/IEC  10165-2  :  1992":  counter; 
BE  HAV I OUR    pdusReasmbl dOKCount erBehav  i  our ; 

REGISTERED  AS        Cx-attribute  38>; 

pdusReasmbldOKCounterBehaviour  BEHAVIOUR 

DEFINED  AS 

!This  attribute  specifies  the  number  of  PDUs  that  were  reassembled  successfully  by  a  protocol  layer 
entity. ! ; 

A.4.4.39  PDUs  Reassembled  Fail  Counter 

pdusReasmbldFai I Counter  ATTRIBUTE 

DERIVED  FROM  "Rec.  X.721  |  ISO/IEC  10165-2  :  1992":  counter; 
BEHAVIOUR    pdusReasmbldFai ICounterBehaviour; 

REGISTERED  AS        Cx-attribute  39>; 

pdusReasmbldFai ICounterBehaviour  BEHAVIOUR 

DEFINED  AS 

!This  attribute  specifies  the  number  of  valid  PDUs  received  by  a  protocol  layer  entity  but  discarded 
due  to  reassembly  failure.    This  attribute  counts  only  incoming  PDUs  which  were  recognized  as  valid 
segments  of  an  SDU,  but  which  were  discarded  during  reassembly  (for  example,  due  to  reassembly  time 
expi  ration) . ! ; 

A.4.4.40  PDUs  Discarded  Counter 

pdusDiscardedCounter  ATTRIBUTE 

DERIVED  FROM  "Rec.  X.721  |  ISO/IEC  10165-2  :  1992":  counter; 
BEHAVIOUR    pdusO  i  scardedCounterBehavi  our ; 

REGISTERED  AS        Cx-attribute  40>; 

pdusDi scardedCounterBehavi our  BEHAVIOUR 
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DEFINED  AS 

IThis  attribute  specifies  the  nuniaer  of  invalid  POUs  received  and  discarded  by  a  protocol  layer 
entity. I; 

A.4.4.41  PeriplMral  Ust 

peripheralList  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX   SYNTAX- 1 .AnyNamesBase; 

MATCHES  FOR  EQUALITY.  SET -COMPARISON,  SET- INTERSECTION; 

BEHAVIOUR   peripheral Li stBehaviour; 

REGISTERED  AS  {x-attribute  41>; 

peripheralListBehaviour  BEHAVIOUR 

DEFINED  AS 

IThe  Peripheral  List  attribute  provides  managed  object  instance  information  for  peripheral  devices 
accessible  by  a  resource. 

The  Peripheral  List  attribute  identifies  the  auxiliary  devices  that  are  used  by  a  resource.  This 
includes  things  such  as  disk  drives,  tape  drives,  printers,  etc. 

The  following  object  classes  (or  their  subclasses  or  allomorphic  classes)  are  valid  processing 
entities:  OMNIPoint  Equipment. 

The  SET -COMPARISON  and/or  SET -INTERSECT I ON  matching  rules  may  not  be  supported  by  some  managed 
object  instances  which  include  this  attribute.!; 

A.4.4.42  Peripheral  Name 

peripheralName  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .AnyNameBase; 
MATCHES  FOR  EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  peripheralNameBehaviour; 

REGISTERED  AS  <x-attribute  42>; 

peripheralNameBehaviour  BEHAVIOUR 

DEFINED  AS 

IThe  Peripheral  Name  attribute  provides  information  for  peripheral  devices  accessible  by  a  resource. 

The  Peripheral  Name  attribute  identifies  an  auxiliary  devices  that  is  used  by  a  resource.  This 
includes  things  such  as  disk  drives,  tape  drives,  printers,  etc. I; 

A.4.4.43  Processing  Entity  Ust 

process ingEntityLi St  ATTRIBUTE 

UITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .AnyNamesBase; 

MATCHES  FOR  EQUALITY,  SET -COMPARISON,  SET- INTERSECTION; 

BEHAVIOUR  processingEntityListBehaviour; 

REGISTERED  AS  Cx-attribute  43>; 

processingEntityListBehaviour  BEHAVIOUR 

DEFINED  AS 
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!The  Processing  Entity  List  attribute  specifies  the  processing  entities  which  may  be  used  by  the 
containing  object  instance  but  which  are  not  contained  in  (i.e.,  processing  entities  which  are 
shared  among  systems).    The  following  object  classes  (or  their  subclasses  or  allomorphic  classes) 
are  valid  processing  entities:  processingEntity. 

The  SET -COMPARISON  and/or  SET- INTERSECTION  matching  rules  may  not  be  supported  by  some  managed 
object  instances  which  include  this  attribute.!; 

A.4.4.44  Processing  Entity  Name 

process ingEntityName  ATTRIBUTE 

UITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .AnyNameBase; 
HATCHES  FOR  EQUALITY,  SUBSTRINGS; 
BEHAVIOUR    process ingEntityNameBehavi our; 

REGISTERED  AS  (x-attribute  44}; 

process  i  ngEnt  i  tyNameBehav  i  our  BE  HAV I OUR 

DEFINED  AS 

•The  Processing  Entity  Name  attribute  specifies  the  processing  entity  which  may  be  used  by  the 
containing  object  instance  but  which  is  not  contained  in  (i.e.,  processing  entities  which  are  shared 
among  systems).!; 

A.4.4.45  Product  Label 

productLabel  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX- 1 .GraphicStringBase; 
MATCHES  FOR      EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  prod'JctLabelBehaviour; 

REGISTERED  AS  <x-attribute  45>; 

productLabelBehaviour  BEHAVIOUR 

DEFINED  AS 

■The  productLabel  attribute  specifies  the  product  number  or  identifying  string  (e.g.,  model  nuaber) 
of  the  underlying  resource.!; 

A.4.4.46  Remote  Network  Address 

remoteNetworkAddress  ATTRIBUTE 

UITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .Address; 
MATCHES  FOR       EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  remoteNetworkAddressBehaviour; 

REGISTERED  AS  <x-attribute  46>; 

remoteNetworkAddressBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  remoteNetworkAddress  attribute  identifies  the  remote  network  address  of  a  transport  connection 
(e.g.,  remote  IP  address  for  TCP  or  the  remote  NSAP  address  for  OSI).!; 

A.4.4.47  Remote  Transport  Connection  Endpoint 

remoteT  ransportConnect  i  onEndpoi  nt         ATTR I BUTE 
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WITH  ATTRIBUTE  SYNTAX     SYNTAX- 1 .Address; 
MATCHES  FOR      EQUALITY.  SUBSTRINGS; 

BEHAVIOUR  remoteTransportConnectionEndpointBehaviour; 
REGISTERED  AS         Cx-attribute  47>; 
remoteTransportConnectionEndpointBehaviour  BEHAVIOUR 
DEFINED  AS 

IThis  attribute  identifies  the  remote  transport  connection  endpoint  (e.g.,  the  destination  port  for 
TCP  or  the  remote  t-selector  for  OSI  Transport  protocol). I; 

A.4.4.48  Retransmission  Time 

retransmissionTime  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX- 1 .HundredthsOf Sec; 
MATCHES  FOR      EQUALITY,  ORDERING; 
BEHAV I OUR    ret  r ansmi  ss  i  onT  i  meBehav  i  our ; 

REGISTERED  AS        {x-attribute  A8>; 

ret ransmissionTi meBehav i our  BEHAVIOUR 

DEFINED  AS 

IThis  attribute  specifies  the  current  value  (in  1/100ths  of  a  second)  of  the  retransmission  timer 
used  by  a  transport  connection.); 

A.4.4.49  Retransmission  Timer  Initial  Value 

retransmissionTimer Initial Value  ATTRIBUTE 

UITH  ATTRIBUTE  SYNTAX     SYNTAX- 1 .HundredthsOf Sec; 

MATCHES  FOR      EQUALITY,  ORDERING; 

BEHAVKXJR  retransmissionTimerlnitialValueBehaviour; 

REGISTERED  AS        (x-attr ibute  49>; 

retransmissionTimerlnitialValueBehaviour  BEHAVIOUR 

DEFINED  AS 

■This  attribute  specifies  the  initial  value  (in  1/100ths  of  a  second)  of  the  retransmission  timer 
used  by  a  transport  connection.!; 

A.4.4.50  Serial  Number 

serialNumber  ATTRIBUTE 

UITH  ATTRIBUTE  SYNTAX     SYNTAX-1 .GraphicStringBase; 
MATCHES  FOR      EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  serialNumberBehaviour; 

REGISTERED  AS  (x-attribute  50>; 

serialNumberBehaviour  BEHAVKXJR 

DEFINED  AS 

I  The  serialNumber  attribute  provides  the  serial  number  of  the  underlying  resource. I; 

A.4.4.51  Service  List 
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serviceList  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  SYNTAX- 1 .AnyNamesBase; 
MATCHES  FOR  SET -COMPARISON,  SET- INTERSECTION; 
BEHAVIOUR  serviceListBehaviour; 

REGISTERED  AS  <x-attribute  51>; 

serviceListBehaviour  BEHAVIOUR 

DEFINED  AS 

(The  Service  List  attribute  provides  managed  object  instance  information  about  one  or  more  services. 
The  following  object  classes  (or  any  of  their  subclasses  or  allomorphic  classes)  are  valid  as 
services:  "0P1  Library  Vol.  4":Service. 

The  SET -COMPARISON  and/or  SET- INTERSECTION  matching  rules  may  not  be  supported  by  some  managed 
object  instances  which  include  this  attribute.!; 

A.4.4.52  Service  Name 

serviceName  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .AnyNameBase; 
MATCHES  FOR  EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  serviceNameBehaviour; 

REGISTERED  AS  <x-attribute  52); 

serviceNameBehaviour  BEHAVIOUR 

DEFINED  AS 

IThe  Service  Name  attribute  provides  information  about  one  service.!; 

A.4.4.53  Software  List 

softwareList  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  SYNTAX- 1 .AnyNamesBase; 
MATCHES  FOR  SET -COMPARISON,  SET- INTERSECTION; 
BEHAVIOUR    sof twareListBehaviour; 

REGISTERED  AS  <x-attribute  53); 

softwareListBehaviour  BEHAVIOUR 

DEFINED  AS 

IThe  Software  List  attribute  identifies  those  software  cooponents  that  run  on  or  are  considered  part 
of  the  equipment.    (There  is  no  corresponding  managed  object  class  at  this  time.) 

The  SET -COMPARISON  and/or  SET- INTERSECTION  matching  rules  may  not  be  supported  by  some  managed 
object  instances  which  include  this  attribute.!; 

A.4.4.54  Software  Name 

softwareName  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .AnyNameBase; 
MATCHES  FOR  EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  softwareNameBehaviour; 

REGISTERED  AS  (x-attribute  54>; 
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softwareNameBehaviour  BEHAVIOUR 
DEFINED  AS 

IThe  Software  Name  attribute  identifies  the  software  component  that  runs  on  or  are  considered  part 
of  the  equipment. ! ; 

A.4.4.55  System  Time 

systemTime  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX-1 .GeneralTime; 
MATCHES  FOR      EQUALITY,  ORDERING; 
BEHAVIOUR  systemTimeBehaviour; 

REGISTERED  AS        {x-attribute  55>; 

systemTimeBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  systemTime  attribute  specifies  the  current  time  clocked  at  the  resource. I; 

A.4.4.56  Transport  Connection  Id 

transportConnectionId  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX-1 .GraphicStringBase; 

MATCHES  FOR    EQUALITY,  SUBSTRINGS; 

BE  HAV I OUR    t  ranspor tConnec t  i  on I dSehav  i  our ; 

REGISTERED  AS        {x-attribute  56>; 

transportConnectionldBehaviour  BEHAVIOUR 

DEFINED  AS 

IThe  transportConnectionId  attribute  is  the  distinguishing  attribute  for  the  transportConnection 
managed  object  class.!; 

A.4.4.57  Transport  Connection  Reference 

transportConnectionReference  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  SYNTAX- 1 . IntegerBase; 

MATCHES  FOR  EQUALITY; 

BEHAVIOUR  transportConnectionReferenceBehaviour; 
REGISTERED  AS  Cx-attr ibute  57>; 

t  ranspor  tConnec  t  i  onRef erenceBehav  i  our     BE  HAV I OUR 
DEFINED  AS 

•This  attribute  identifies  the  local  transport  connection  reference  that  is  established  by  the  two 
transport  connection  endpoints  (e.g.,  the  local  socket  number  for  TCP  or  the  local  connection 
reference  for  OSI ) . ! ; 

A.4.4.58  Transport  Entity  Type 

transportEntityType  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX      SYNTAX-1 .TransportEntityType; 
MATCHES  FOR  EQUALITY; 
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BEHAVIOUR    transportEnti  tyTypeBehaviour; 
REGISTERED  AS         {x-attribute  58}; 
transportEnti tyTypeBehaviour  BEHAVIOUR 
DEFINED  AS 

IThe  transportEnti tyType  attribute  indicates  the  type  of  the  transport  protocol  layer  entity. I; 

A.4.4.59  Type  Text 

typeText  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX-1 .GraphicStringBase; 
MATCHES  FOR      EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  typeTextBehaviour; 

REGISTERED  AS  {x-attribute  59}; 

typeTextBehaviour  BEHAVIOUR 

DEFINED  AS 

'The  typeText  attribute  serves  to  supplement  and  refine  individual  managed  object  class  attributes. 
If  none  of  the  named  items  defined  for  the  "type"  attribute  are  appropriate,  or  the  "type"  attribute 
requires  refinement,  the  typeText  attribute  contains  supplemental  information.!; 

A.4.4.60  Up  Time 

upTime  ATTRIBUTE 

UITH  ATTRIBUTE  SYNTAX     SYNTAX-1 . IntegerBase; 
MATCHES  FOR      EQUALITY,  ORDERING; 
BEHAVIOUR  upTimeBehaviuur; 

REGISTERED  AS        {x- attribute  60}; 

upTimeBehaviour  BEHAVIOUR 

DEFINED  AS 

IThe  upTime  attribute  specifies  the  time  interval  (in  seconds)  that  has  elapsed  since  the  entity's 
operational  state  changed  to  "enabled",  or  since  the  time  that  the  entity  was  created  in  the 
"enabled"  state.!; 


A.4.4.61  Vendor  List 

vendorList  ATTRIBUTE 

UITH  ATTRIBUTE  SYNTAX  SYNTAX-1 .AnyNamesBase; 
MATCHES  FOR  SET -COMPARISON.  SET- INTERSECTION; 
BEHAVIOUR  vendorListBehaviour; 

REGISTERED  AS  <x-attribute  61}; 

vendorListBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  Vendor  List  attribute  provides  managed  object  instance  information  about  a  set  of  vendor 
organizations.  The  following  classes  (or  any  of  their  subclasses  or  allomorphic  classes)  are  valid 
as  vendors:    "0P1  Library  Vol.  4":Vendor. 
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The  SET -COMPARISON  and/or  SET -INTERSECT I ON  matching  rules  may  not  be  supported  by  some  managed 
object  instances  which  include  this  attribute.!; 


A.4.5  Actions 


A.4.5.1  Activate 

-•  Copied  from  ISO/IEC  DIS  10737,  should  be  replaced  by  reference  to  standard 
--  definition  when/if  this  ACTION  is  registered  in  a  final  IS  version. 

activate  ACTION 

BEHAVIOUR  activateBehaviour; 
NODE  CONFIRMED; 

WITH  REPLY  SYNTAX  SYNTAX-1 .ActivateActionReply; 
REGISTERED  AS  {  x-action  1  ); 


activateBehaviour  BEHAVIOUR 
DEFINED  AS 

(This  action  initializes  the  operation  of  the  resource.    As  a  result  of  the  action,  the  sequence  of 
operations  necessary  to  cause  the  resource  to  enter  its  operational  mode  shall  be  initiated.  These 
may  include,  for  example,  checks  against  attribute  constraint  violation  and  checks  on  the  validity 
of  relationship  attributes  (cross-layer  and  other).    If  these  operations  are  successfully  initiated, 
the  administrative  state  (if  present)  shall  be  changed  to  "unlocked"  and  the  value  "successResponse" 
shall  be  returned  in  the  responseCode  parameter  of  the  action  reply.    If  these  operations  cannot  be 
successfully  initiated,  the  value  "fai lureResponse"  shall  be  returned,  together  with  a  failure 
reason  parameter  describing  the  reason  for  the  failure.    On  successful  completion  of  these 
operations,  the  operational  state  shall  have  the  value  "enabled".    Depending  upon  the  current  state 
of  the  resource  when  the  action  is  attempted,  some  or  all  of  the  above  operations  may  be 
-  unnecessary.!; 

A.4.5.2  Deactivate 

--  Copied  from  ISO/IEC  DIS  10737,  should  be  replaced  by  reference  to  standard 
-•  definition  when/if  this  ACTION  is  registered  in  a  final  IS  version. 

deactivate  ACTION 

BEHAVIOUR  deactivateBehaviour; 
NODE  CONFIRMED; 

WITH  REPLY  SYNTAX  SYNTAX-1 .ActivateActionReply; 
REGISTERED  AS  C  x-action  2  >; 


deactivateBehaviour  BEHAVICXJR 
DEFINED  AS 

•This  action  terminates  the  operation  of  the  resource.    As  a  result  of  the  action,  the  sequence  of 
operations  necessary  to  cause  the  resource  to  cease  operation  shall  be  initiated.    If  these 
operations  are  successfully  initiated,  the  administrative  state  (if  present)  shall  be  changed  to 
"locked"  and  the  value  "successResponse"  shall  be  returned  in  the  responseCode  parameter  of  the 
action  reply.    If  these  operations  cannot  be  successfully  initiated,  the  value  "fai lureResponse" 
shall  be  returned,  together  with  a  failure  reason  parameter  describing  the  reason  for  the  failure. 
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On  successful  completion  of  these  operations,  the  operational  state  shall  have  the  value  "disabled**. 
Depending  upon  the  current  state  of  the  resource  when  the  action  is  attempted,  some  or  all  of  the 
above  operations  may  be  unnecessary.!; 


A.4.6  Parameters 


A.4.6.1  Transport  Disconnect  Cause 

transportDisconnectCause  PARAMETER 

CONTEXT      EVENT- INFO; 

WITH  SYNTAX  SYNTAX- 1 .Cause; 

BEHAVIOUR  causeBehaviour; 

REGISTERED  AS  <  x-parameter  1  >; 


causeBehaviour  BEHAVIOUR 


DEFINED  AS 

■This  parameter  specifies  the  reason  why  a  transport  connection  was  deleted.  It  may  be  included  in 
the  Additional  Information  parameter  of  the  objectDeletion  notification.); 


A.4.7  Syntax  Definitions 


SYNTAX-1  <  x-module  1  > 
DEFINITIONS  IMPLICIT  TAGS  ::=  BEGIN 

IMPORTS  DistinguishedName  FROM  InformationFramework  Cjoint-iso-ccitt  ds(5)  modules(l) 

informationFrameworkd)}  Objectlnstance  FROM  CMIP-1  Cjoint-iso-ccitt  ms(9)  cmipd)  modules(O)  protocol(3)>; 


EXPORTS  everything 


The  following  OIDs  are  allocated  from  the  OIU  NMSIG  registration  arc, 
for  use  in  registering  harmonized  OIW/NMF  definitions. 


nmsig 

opiLibraryVoll 
x-module 
x-objectClass 
x-package 
nameBinding 
attribute 
attributeGroup 
parameter 
action 

notification 
responseCode 


OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 


IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 


FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 


=  <  iso  identif ied-organization(3}  oiw(14)  nmsig(2)  > 
=    {  nmsig  2  > 

> 
> 
> 
> 
> 
> 
> 


=  { 

=  { 

=  i 

=  C 

=  C 


{  opIL 
opiL 
opiL 
opiL 
opIL 
opiL 
(  opIL 
{  opIL 
i  opIL 
€  opIL 


braryVoll  0 
braryVoll  1 
braryVoll 
braryVoll 
braryVoll 
braryVoU 
braryVoll 
braryVoll  7  > 
braryVoH  8  > 
braryVoll  9  > 


By  convention,  the  postfix  "base"  is  used  when  defining  base  types  which  appear 

as  syntax  labels  in  ATTRIBUTE  templates  and  the  postfix  "range"  is  used  when  defining 

constrained  types  which  appear  as  syntax  labels  in  PERMITTED  VALUES  clauses. 
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ActivateActionReply 


SEQUENCE  < 

responseCode 
responseArgs 
> 


OBJECT  IDENTIFIER, 

SET  OF  Parameter  OPTIONAL 


--  OBJECT  IDENTIFIER  values  used  with  ActivateActionReply  -- 
fai lureResponse  OBJECT  IDENTIFIER  ::=  <  x- responseCode  1  > 
successResponse   OBJECT  IDENTIFIER         {  x- responseCode  2  > 


Address 


::=    OCTET  STRING 


Address  i  ngS  i  zeBase 


::=  CHOICE  i 

unknown  NULL, 

address ingSize  IntegerBase 


measured  in  bits 


Address  i  ngS  i  zeRange 


::=  CHOICE  { 

unknown  NULL, 

address ingSize       IntegerBase  (1 . .64) 


measured  in  bits 


AnyNamesBase 
AnyNameBase 


:=  SET  OF  Object  Instance 
:=    Graph icStringSase 


AnyNamesRange 
AnyNameRange 


::=  SET  SIZE(0..64)  OF  Object  Instance 
::=  GraphicString64 


Cause 


:=    SEQUENCE  i 


Endianess 


who  INTEGER  ( 

unknown  (0), 

user  (1), 

provider  (2) 
>, 

why  INTEGER  { 

unknown  (0), 

excessiveldle  (1), 
excess iveRetransmiss ions  <2) 


ENUMERATED  i 

big  (1), 
little  (2) 
> 


Equipment IdRange 


CHOICE  < 

based  on  "Rec.  M.3100  :  1992"  ASN.1  Module  NameType 
numericName  Integer32, 
pString  GraphicString64 
> 


GeneralTime 


General izedTi me 


Graph icStringBase  ::=  GraphicString 

GraphicString16  ::=   GraphicStringBase(SIZE(0. .16)) 
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Graph icString32 
Graph icString64 


GraphicStringBase(SIZE(0..32)) 
GraphicStringBase(SIZE(0..6A)) 


HundredthsOfSec 


:=  IntegerBase 


IntegerBase 
Integer32 


INTEGER 

::»  IntegerBase(0..429A967295) 


MemorySizeBase 


CHOICE  { 
unknown  NULL, 

size  IntegerBase 
> 


measured  in  kilobytes 


MemorySizeRange 


CHOICE  { 

unknown  NULL, 

size 

> 


Integer32 


--  measured  in  kilobytes 


NetworkEnt  i  tyType 


::=  INTEGER  (  other  (0), 

oSI-clnp  (1), 

internet- IP  (2) 
>  (0..255) 


NetworkAddresses 


SET  OF  Address 


OsInfoBase 


SET  OF  SEQUENCE 
C 

osName  GraphicStringBase, 
osRelease  GraphicStringBase 
> 


OsInfoRange 


SET  OF  SEQUENCE 
i 

osName  GraphicString64, 
osRelease  GraphicString64 
> 


Parameter 


SEQUENCE  { 

paramid       OBJECT  IDENTIFIER, 
paramlnfo    ANY  DEFINED  BY  paraiPid 
> 


PercentageRange 


:=    IntegerBase  (0..100} 


T  ranspor  t Addresses 


:=    SET  OF  T ranspor tAddress 


TransportAddress 


::=    SEQUENCE  C 

transportConnectionEndpoint  Address, 
networkAddress  Address 
> 
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TransportEnt  i  tyType 


::-  INTEGER  <  other  (0), 

oSI-TP  (1), 

tCP  (2), 

SNA  (3) 
}  (0..255) 


END 


A.4.8  Inheritance  &  Naming  Trees 

This  section  provides  graphic  depictions  for  the  inheritance  and  naming  trees  that  are  defined  in  the 
previous  sections. 

A.4.8. 1  Inheritance  Tree 


top  opEquipment   

■-  computerSystem 

■*  opNetwork 

•-  coTransportProtocolLayerEntity 

■-  clNetMorkProtocolLayerEntity 

♦--  transportConnection 


process ingEntity 


A.4.8.2  Naming  Tree 


root         opNetwork  --+- 
I  I 
I 

+•- 
I 
I 

+- 


opNetwork 

computerSysteoi 

opEquipment 


+--  DMI  system  coTransportProtocolLayerEntity 
! 

clNetworkProtocolLayerEntity 


transportConn 


-  opEquipment*-*-"  opEquipment 


I 
I 

process ingEntity 

I 
I 

CoTransportProtocolLayerEntity  --  transportConn 

j 

ClNetworkProtocolLayerEntity 


I 

*--  computerSystem 


computerSystem 


process ingEntity 


opEquipment 
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coTransportProtocolLayerEntity  --  transportConn 

I 
I 

+- -  c iNetworkProtocol LayerEnt i ty 


A.5  OIW  NMSIG  IVMO  Definitions 

The  definitions  specified  in  tiiis  clause  can  be  referenced  by  using  the  label  "0P1  Library  Vol.  2"  (e.g.. 
"0P1  Library  Vol.  2":transportConnectionlVMO). 

A.5.1  Managed  Object  Classes  and  Mandatory  Packages 

A.5.1.1  Transport  Connection  IVMO 


transportConnectionlVMO     MANAGED  OBJECT  CLASS 

DERIVED  FROM  "Rec.  X.721  j  ISO/ItC  10165-2  :  1 992": top; 
CHARACTERIZED  BY  transportConnectionlVMO-Package; 

REGISTERED  AS  {y-objectClass  1>; 


t  ranspor t  Connec  t  i  on I VMO -Package  PACKAGE 

BE  H AV I OUR    t  ranspor  t Connec  t  i  on I VMO - beha v  i  our ; 
ATTRIBUTES 

t ranspor tConnectionlVMOId  GET, 

"0P1  Library  Vol.  1":inactivityTimeout    PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET-REPLACE, 
"0P1  Library  Vol.  1":maxPDUSize    PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET-REPLACE; 
NOTIFICATIONS 

"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":objectCreation, 
"Rec.  X.721  ISO/IEC  10165-2  :  1992":objectDeletion, 
"Rec.  X.721  !  ISO/IEC  10165-2  :  1992":attributeValueChange; ; 


t  ranspor tConnec  t  i  onl VMO- behav  i  our    BE  HAV I OUR 
DEFINED  AS 

■This  managed  object  class  is  an  IVMO  (Initial  Value  Managed  Object  class).    It  represents 
the  collection  of  characteristic  attributes  which  supply  default  and  initially  advertised 
attribute  values  to  be  used  by  instances  of  the  Transport  Connection  managed  object  class 
when  they  are  created.    There  can  be  only  one  instance  of  the  Transport  Connection  IVMO 
managed  object  class  for  each  instance  of  the  CO  Transport  Protocol  Layer  Entity  managed 
object  class.    Each  Transport  Connection  IVMO  instance  may  provide  initial  attribute  values 
for  newly-created  Transport  Connection  instances  with  the  same  superior. 

The  Attribute  List  parameter  of  the  ObjectCreation  notification  shall  contain  all  the 
attributes  of  the  created  transport  connection  IVMO  instance. 

The  Attribute  List  parameter  of  the  ObjectDeletion  notification  shall  contain  all  the 
attributes  of  the  delisted  transport  connection  IVMO  instance. 

Attributes  that  are  subject  to  the  AttributeValueChange  notification  are  :  "^1  Library 
Vol.  1": inactivityTimeout,  "0P1  Library  Vol.  1":maxPDUSize.    All  attributeValueChange 
notifications  shall  include  the  Attribute  Identifier  List  parameter. I; 


A.5.t.2  Transport  Connection  Retransmission  IVMO 
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transportConnectionRetransmissionlVMO     MANAGED  OBJECT  CLASS 
DERIVED  FROM     t ransport Connect  ion I VMO; 

CHARACTERIZED  BY  transportConnectionRetransmissionlVMO-Package; 
REGISTERED  AS    <y-objectClass  3>; 


t  ransportConnec t  i  onRet  ransmi  ss  i  onl VMO- Package  PACKAGE 
BEHAV I OUR    t  ransportConnect  i  onl VMO- behavi  our; 
ATTRIBUTES 

"0P1  Library  Vol.  1":maxRet ransmi ss ions  PERMITTED  VALUES  SYNTAX-1 . Integer32  GET-REPLACE, 
"OPI  Library  Vol.  V'rretransmissionTimerlnitialValue 

PERMITTED  VALUES  SYNTAX-1 . Integer32  GET-REPLACE;; 


t ransportConnec t  i  onRet  ransmi  ss  i  onl VMO- behav i  our    BE HAV I OUR 
DEFINED  AS 

•This  managed  object  class  is  an  IVMO  (Initial  Value  Managed  Object  class).    It  represents 
the  collection  of  characteristic  attributes  which  supply  default  and  initially  advertised 
attribute  values  to  be  used  by  instances  of  the  Transport  Connection  managed  object  class 
that  support  retransmission,  when  they  are  created.    There  can  be  only  one  instance  of  the 
Transport  Connection  Retransmission  IVMO  managed  object  class  for  each  instance  of  the  CO 
Transport  Protocol  Layer  Entity  managed  object  class.    Each  Transport  Connection 
Retransmission  IVMO  instance  may  provide  initial  attribute  values  for  newly-created 
Transport  Connection  instances  with  the  same  superior. 

Attributes,  additional  to  those  inherited  from  the  transport  connection  IVMO  managed  object 
class,  that  are  subject  to  the  AttributeValueChange  notification  are  :  "OPI  Library  Vol. 
1":maxRet ransmi ss ions,  "OPI  Library  Vol.  1":retransmissionTimerInitialValue.!; 


A.5.2  Name  Bindings 


A.5.2.1  Transport  Connection  IVIMO  Name  Bindings 

transportCormectionlVMO-coTransportProtocolLayerEntity   NAME  BINDING 

SUBORDINATE  OBJECT  CLASS  transportConnectionlVMO  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS  "0P1  Library  Vol.  1":coTransportProtocolLayerEntity  AND  SUBCLASSES; 
WITH  ATTRIBUTE  transportConnectionlVMOId; 
REGISTERED  AS    Cy-nameBinding  1>; 


A.5.2.2  Transport  Connection  Retransmission  IVMO  Name  Bindings 

transportConnecti onRet ransmi ssionlVMO-coTransportProtocolLayerEntity  NAME  BINDING 
SUBORDINATE  OBJECT  CLASS  transportConnectionRetransmissionlVMO 
AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS  "OPI  Library  Vol.  1":coTransportProtocolLayerEntity  AND  SUBCLASSES; 
WITH  ATTRIBUTE  transportConnectionlVMOId; 
REGISTERED  AS    Cy-nameBinding  2>; 


A.5.3  Attributes 
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A.5.3.1  Transport  Connection  IVMO  Id 


t ranspor t Connect  ion I VMO Id  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX°1 .GraphicStringBase; 

MATCHES  FOR     EQUALITY,  SUBSTRINGS; 

BE  H AV I OUR    t  ranspor  t Connec  t  i  on I VMO I dBeha v  i  our ; 


REGISTERED  AS 


€y-attribute  1>; 


t  ranspor t  Connec  t  i  on I VMO I dBeha v  i  our     BE  H AV I OUR 

DEFINED  AS  IThis  attribute  is  the  distinguishing  attribute  for  the  managed  object  class 

transportConnectionlVMO. I ; 

A.5.4  Syntax  Definitions 


SYNTAX-2  <  y-module  1  > 
DEFINITIONS  IMPLICIT  TAGS 


:=  BEGIN 


EXPORTS  everything 

The  following  OIDs  are  allocated  from  the  OIU  NMSIG  registration  arc, 
for  use  in  registering  OIU  NMSIG  MIL  definitions. 


nmsig  OBJECT  IDENTIFIER 

oplLibraryVol2  OBJECT  IDENTIFIER 

y-module  OBJECT  IDENTIFIER 

y-objectClass  OBJECT  IDENTIFIER 

y-package  OBJECT  IDENTIFIER 

y-nameBinding  OBJECT  IDENTIFIER 

y-attribute  OBJECT  IDENTIFIER 

y-attributeGroup  OBJECT  IDENTIFIER 

y-parameter  OBJECT  IDENTIFIER 

y-action  OBJECT  IDENTIFIER 

y-notif ication  OBJECT  IDENTIFIER 


=  ( 

=  { 

=  { 

=  i 

=  <. 

=  i 

=  C 

=  < 

=  c 

=  { 


iso  identif ied-organization(3)  oiw(14)  nmsig(2)  > 
nmsig  1  > 

op1LibraryVol2  0  > 
oplLibraryVol2  1  > 
op1LibraryVol2  2  > 
op1LibraryVol2  3  > 
oplLibraryVol2  4  > 
op1LibraryVol2  5  > 
op1LibraryVol2  6  > 
oplLibraryVol2  7  > 
op1LibraryVol2  8  } 


END 


A.5.5  Inheritance  &  Naming  Trees 

This  section  provides  graphic  depictions  for  the  inheritance  and  naming  trees  that  are  defined  in  the 
previous  sections. 

A.5.5.1  Inheritance  Tree 


top    transportConnectionlVMO 


transportConnectionRetransmissionlVMO 


A.5.5.2  Naming  Tree 


coTransportProtocolLayerEntity  -■»■--  transportConnection 
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j 

♦--  transportConnectionlVMO 
I 

♦ - -  t  ranspor tCormec t  i  onRet  ransmi  ss  i  onl VMO 


A.6  08W  NMSIG  Shared  Management  Knowledge  (SMK)  Definitions 

(Refer  to  the  Working  Implementation  Agreements  Document.) 
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Annex  B  (Informative) 
NMSIG  Object  Identifiers 

(Refer  to  the  Working  Implementation  Agreements  Document  for  additional  information.) 
B.I  Introduction 

This  Annex  (B)  specifies  object  identifier  component  values  which  are  globally  unambiguous.  These  object 
identifiers  are  to  be  used  when  referencing  NMSIG-specified  information  objects.  As  defined  in  Part  6  of 
these  agreements,  the  OIW  has  assigned  the  following  object  identifier  for  use  by  the  NMSIG: 

{  iso(1)  identified-organization(3)  oiw(14)  nmsig(2)  } 

The  following  object  identifiers  are  assigned  under  the  {  iso  identified-organization  oiw  nmsig  }  node, 
labelled  "nmsig". 


Table  B.l  -  Object  identifiers  assigned  under  "nmsig"  node 


Identifier 

Value 

Reference 

op1LibraryVol2 

1 

A. 5 

opILibraryVoll 

2 

A. 4 

By  inclusion  of  the  managed  object  (MO)  definitions  and  the  object  identifiers  in  Annex  A  and  Annex  B, 
respectively,  of  the  Stable  Implementors'  Agreements  (SIAs),  these  managed  object  (MO)  definitions  have 
become  formally  registered.  Implementors  of  part  18  of  the  SIAs  do  not  have  to  support  any  of  these  MOs. 
However,  even  though  Annex  A  and  Annex  B  are  informative  annexes,  any  implementation  that  claims  to 
conform  to  these  definitions  must  treat  these  definitions  as  normative  and  comply  with  the  relevant  portions 
of  Annex  A.4  and  A.5,  and  Annex  B. 


B.2  Harmonized  MiL  Object  Identifiers 


Harmonized  MIL  Object  Identifiers  are  assigned  under  the  "nmsig"  node  as  follows: 


nmsig  OBJECT  IDENTIFIER 

opILibraryVoll  OBJECT  IDENTIFIER 

x-module  OBJECT  IDENTIFIER 

x-objectClass  OBJECT  IDENTIFIER 

x-package  OBJECT  IDENTIFIER 

x-nameBinding  OBJECT  IDENTIFIER 

x-attribute  OBJECT  IDENTIFIER 

x-attributeGroup  OBJECT  IDENTIFIER 

x-parameter  OBJECT  IDENTIFIER 

x-action  OBJECT  IDENTIFIER 

x-notif ica£ion  OBJECT  IDENTIFIER 

x-responseCode  OBJECT  IDENTIFIER 


{  iso  identif ied-organization(3)  oiw(H)  nnisig(2)  > 
{  nmsig  2  ) 

} 
> 
> 
> 
> 
> 
> 
) 


opUibraryVol  1 
opILibraryVoll 
opILibraryVoll 
opILibraryVoll 
opILibraryVoll 
opILibraryVoll 
opILibraryVoll 
{  opILibraryVoll 
{  opILibraryVoll  8  ) 
{  opILibraryVoll  9  ) 


8.2. 1  Object  Class  Object  identifiers 
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The  following  object  identifiers  are  assigned  under  the  {  x-objectClass  }  node: 

Table  B.2  -  Object  identifiers  assigned  under  "x-objectClass"  node 


Reference 

Identifier 

Value 

A. 4, 1.1 

computerSystem 

1 

A. 4, 1.2 

coTransportProtocolLayerEnt  i  ty 

2 

A. 4. 1.3 

clNetworkProtocolLayerEnti  ty 

3 

A. 4. 1.4 

opEquipment 

4 

A. 4. 1.5 

opNetwork 

5 

A. 4. 1.6 

process  i  ngEnt  i  ty 

6 

A. 4. 1.7 

t ranspor t Connec t i on 

7 

B.2.2  Package  Object  Identifiers 

The  following  object  identifiers  are  assigned  under  the  {  x-package  }  node: 


Table  B.3  -  Object  identifiers  assigned  under  "x-package"  node 


Reference 

Identifier 

Value 

A, 4, 2.1 

address ingPkg 

1 

A. 4. 2. 2 

checksumPDUsDiscardedPkg 

2 

A. 4. 2. 3 

contactListPkg 

3 

A. 4. 2. 4 

contactNamePkg 

4 

A. 4. 2. 5 

cpuUti I izationPkg 

5 

A. 4. 2. 6 

customerListPkg 

6 

A. 4. 2. 7 

customerNamePkg 

7 

A. 4. 2. 8 

functionListPkg 

8 

A. 4. 2. 9 

functionNamePkg 

9 

A. 4, 2. 10 

incomingProtocolErrorPkg 

10 

A. 4. 2. 11 

I ocat  i  onPoi  nterPkg 

11 

A. 4. 2. 12 

manuf acturerL  i  stPkg 

12 

A. 4. 2. 13 

manuf acturerNamePkg 

13 

A. 4. 2. 14 

maxPDUSizelVPkg 

14 

A. 4. 2. 15 

maxRet  ransmi  ss  i  onsPkg 

15 
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Reference 

Identifier 

Value 

A. 4. 2. 16 

memorySizePkg 

16 

A. 4. 2. 17 

memoryUti lizationPkg 

17 

A. 4. 2. 18 

octetsRetransmi  ttedPkg 

18 

A. 4. 2. 19 

opNetworkListPkg 

19 

A. 4. 2. 20 

opNetworkNamePkg 

20 

A. 4. 2. 21 

opVersionPkg 

21 

A. 4. 2. 22 

outgoingProtocolErrorPkg 

22 

A. 4. 2. 23 

pdusRetransmi  ttedCounterPkg 

23 

A. 4. 2. 24 

pdusRetransmi ttedThresholdPkg 

24 

A. 4. 2. 25 

peripheral ListPkg 

25 

A. 4. 2. 26 

peripheralNamePkg 

26 

A. 4. 2. 27 

process  i  ngEnt  i  tyL  i  stPkg 

27 

A. 4. 2. 28 

process! ngEnt  i  tyNamePkg 

28 

A.4„2.29 

productLabelPkg 

29 

A. 4. 2. 30 

ret  r ansmi  ss  i  onT  i  mePkg 

30 

A. 4. 2. 31 

ret  r ansmi  ss  i  onT  i  mer I n  i  t  i  a  I Va I uePkg 

31 

A. 4. 2, 32 

serialNumberPkg 

32 

A. 4. 2. 33 

serviceListPkg 

33 

A. 4. 2. 34 

serviceNamePkg 

34 

A. 4. 2. 35 

sof twareListPkg 

35 

A. 4. 2. 36 

sof twareNamePkg 

36 

A. 4. 2. 37 

system! imePkg 

37 

A. 4. 2. 38 

typeTextPkg 

38 

A. 4. 2. 39 

upTimePkg 

39 

A. 4. 2. 40 

usageStatePkg 

40 

A. 4. 2. 41 

vendorListPkg 

41 

B.2.3  Name  Bindings  Object  identifiers 

The  following  object  Identifiers  are  assigned  under  the  {  x-nameBindIng  }  node: 
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Table  B.4  -  Object  identifiers  assigned  under  "x-nameBinding"  node 


Reference 

Identifier 

Value 

A. 4. 3. 2 

c ompu t erSy s t em- sy s t em 

1 

A. 4. 3. 2 

computerSystem-opNetwork 

2 

A. 4. 3. 2 

computerSystem-computerSystem 

3 

A. 4. 3. 3 

coTransportProtocolLayerEnti ty-computerSystem 

4 

A. 4. 3. 3 

coTransportProtocolLayerEnti  ty- system 

5 

A, 4. 3. 3 

coT  ransportProtocol LayerEnt  i  ty- opEqui  pment 

6 

A. 4. 3. 4 

clNetworkProtocolLayerEnt i  ty-computerSystem 

7 

A. 4. 3. 4 

c INetworkProtoco I LayerEnt  i  ty- system 

8 

A. 4. 3. 4 

ClNetworkProtocolLayerEnt i  ty-opEqui pment 

9 

A. 4. 3. 5 

opEqui pment -computerSystem 

10 

A. 4. 3. 5 

opEqui  pment -  system 

11 

A. 4. 3. 5 

opE  qu  i  pment - equ  i  pmen  t 

12 

A, 4. 3. 5 

opEqui pment -opNetwork 

13 

A. 4. 3. 6 

network-opNetwork-1 

14 

A. 4. 3. 6 

network-opNetwork-2 

15 

A. 4, 3. 6 

opNetwork- root 

16 

A. 4. 3. 8 

t ransport Connect  ion- coT ransportProtocol LayerEnt ity 

17 

B.2.4  Attribute  Object  Identifiers 

The  following  object  Identifiers  are  assigned  under  the  {  x-attribute  }  node: 


Table  B.5  -  Object  identifiers  assigned  under  "x-attribute"  node 


Reference 

Identifier 

Value 

A, 4. 4.1 

ac  t  i  veConnec t  i  ons 

1 

A. 4. 4. 2 

address ingSize 

2 

A. 4. 4. 3 

checksumPDUsD  i  scardedCounter 

3 

A. 4. 4. 4 

computerSystemId 

4 

A. 4. 4. 5 

clNetworkProtocolLayerEnti  tyld 

5 

A. 4. 4. 6 

CoTransportProtocolLayerEnti ty Id 

6 

A. 4. 4. 7 

contactList 

7 
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Reference 

Identifier 

Value 

A. A. 4. 8 

contactName 

8 

A. 4. 4. 9 

cpuType 

9 

A.4.4.1C 

cpuUti lization 

10 

A. 4. 4. 11 

customerList 

11 

A. 4. 4. 12 

customerName 

12 

A. 4. 4. 13 

endianess 

13 

A. 4. 4. 14 

functionList 

14 

A. 4. 4. 15 

functionName 

15 

A. 4. 4. 16 

inacti vi  tyTime 

16 

A. 4, 4. 17 

i  nact  i  v  i  tyT  i  meout 

17 

A. 4. 4. 18 

localNetMorkAddress 

18 

A. 4. 4. 19 

I  oca  I NetworkAddresses 

19 

A. 4. 4. 20 

I oca  I  Transport Addresses 

20 

A. 4. 4. 21 

I oca  I T  r anspor  t Connec  t  i  onE ndpo  i  nt 

21 

A. 4. 4. 22 

locationPointer 

22 

A. 4. 4. 23 

manufacturerList 

23 

A. 4. 4. 24 

manufacturerName 

24 

A. 4. 4. 25 

maxConnections 

25 

A. 4. 4. 26 

maxPDUSize 

26 

A. 4. 4. 27 

maxRetransmissions 

27 

A. 4. 4. 28 

memorySize 

28 

A. 4. 4. 29 

memoryUt  i I i  zat  i  on 

29 

A. 4. 4. 30 

networkEnt  i  tyType 

30 

A. 4. 4. 31 

network! i tie 

31 

A. 4. 4. 32 

npduTimeToLive 

32 

A. 4. 4. 33 

opEquipmentList 

33 

A. 4. 4. 34 

opNetworkList 

34 

A. 4. 4. 35 

opNetuorkName 

35 

A. 4. 4. 36 

osinf 0 

36 

A. 4. 4. 37 

pdusForwardedCounter 

37 

A. 4. 4. 38 

pdusReasmbldOkCounter 

38 

A. 4. 4. 39 

pdusReasmbldFai ICounter 

39 

93 


PART  18:  Network  Management 


December  1992  (Stable) 


ReferefKe 

Identifier 

Value 

A. 4. 4. 40 

40 

A. 4. 4. 41 

per  i  phcra I L  i  st 

41 

L  L  L  L'? 

ijci  1  unci  dinciMic 

L"? 

HC 

A.  4. 4. 43 

A. 4. 4. 44 

nmrp*^^  i  noFnt"  i  t" vWamf* 

44 

A. 4. 4. 45 

oroduc t  L  abe I 

45 

Ik  L  L  Lf^ 

M ■ H • H • HO 

1  dllU  t  cnc  LMUl  KMUUI  Cos 

HO 

1  ClilU  L  C  1  1  ClI  loUUi   LlxLII  II  ICC  I  1  Lfl  Id  lUIJU  1  1 1  L 

L7 

H  1 

A. 4. 4. 48 

rpt  ran^mi      i  onT  i 

48 

A.  4. 4. 49 

PA^  partem!  cci  pir»T  i  mop  to 

1  CLI  diloiilloslUIII  IIIICI  till  \.  IdlVdlLJC 

HT 

bCI  1  d  I  NUinuci 

A. 4. 4. 51 

5^ 

A. 4. 4. 52 

serviceName 

52 

A. 4. 4. 53 

sof twareList 

53 

A. 4. 4. 54 

sof twareName 

54 

A. 4. 4. 55 

systemTime 

55 

A. 4. 4. 56 

transport Connect  ion Id 

56 

A. 4. 4. 57 

transportConnect ionRef erence 

57 

A. 4. 4. 58 

transportEnt i  tyType 

58 

A. 4. 4. 59 

typeText 

59 

A. 4. 4. 60 

upTime 

60 

A. 4. 4. 61 

vendorList 

61 

B.2.5  Action  Object  Identifiers 

The  following  object  identifiers  are  assigned  under  the  {  x-action  }  node: 


Table  B.6  -  Object  identifiers  assigned  under  "x-action"  node 


Reference 

Identifier 

Value 

A. 4. 5.1 

activate 

1 

A. 4. 5. 2 

deactivate 

2 
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B.2.6  Parameter  Object  Identifiers 

The  following  object  identifiers  are  assigned  under  the  {  x-parameter  }  node: 

Table  B.7  -  Object  identifiers  assigned  under  "x-parameter"  node 


Reference 

Identifier 

Value 

A. 4. 6.1 

t ransportD  i  sconnectCause 

1 

B.2.7  Response  Code  Object  Identifiers 

The  following  object  identifiers  are  assigned  under  the  {  x-responseCode  }  node: 

Table  B.8  -  Object  identifiers  assigned  under  "x-responseCode"  node 


Reference 

Identifier 

Value 

A. 4. 7 

fai lureResponse 

1 

A. 4. 7 

successResponse 

2 

B.2.8  Module  Object  Identifiers 

The  following  object  identifiers  are  assigned  under  the  {  x-module  }  node: 

Table  B.9  -  Object  identifiers  assigned  under  "x-module"  node 


Reference 

Identifier 

Value 

A. 4. 7 

SYNTAX- 1 

1 

B.3  Pliase  MAIL  Object  Identifiers 

Phase  1  MIL  Object  Identifiers  are  assigned  under  the  "nmsig"  node  as  follows: 


op1LibraryVol2  OBJECT  IDENTIFIER 

y-module  OBJECT  IDENTIFIER 

y-objectClass  OBJECT  IDENTIFIER 

y-package  OBJECT  IDENTIFIER 

y-nameBinding  OBJECT  IDENTIFIER 

y-attribute  OBJECT  IDENTIFIER 

y-attributeGroup  OBJECT  IDENTIFIER 

y-parameter  OBJECT  IDENTIFIER 

y-action  OBJECT  IDENTIFIER 

y-notif ication  OBJECT  IDENTIFIER 


i  nmsig 
{  op1Li 
{  oplLi 
{  opiLi 
{  opILi 
{  opILi 
C  opiLi 
{  oplLi 


{  opILi 


1  > 
braryVolZ 
braryVol2 
braryVol2 
braryVol2 
braryVol2 
braryVol2 
brary\/ol2 
brary\/ol2 


=    {  op1LibraryVol2  8 


B.3.1  Object  Class  Object  Identifiers 
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The  following  object  identifiers  are  assigned  under  the  {  y-objectClass  >  node: 

Table  B.10  -  Object  identifiers  assigned  under  "y-objectClass"  node 


Reference 

Identifier 

Value 

A. 5. 1.1 

t  r anspor  t  Connec  t  i  on I VMO 

1 

A. 5. 1.2 

t ransportConnec t  i  onRet  ransmi  ssi  onl VMO 

3  [See  note 
below] 

Note:  [Previous  version  (value  2)  has  been  deprecated  in  favor  of  this  version  (value  3).] 
B.3.2  Name  Bindings  Object  Identifiers 

The  following  object  identifiers  are  assigned  under  the  {  y-nameBinding  }  node: 


Table  B.ll  -  Object  identifiers  assigned  under  "y-nameBinding"  node 


Reference 

Identifier 

Value 

A. 5. 2.1 

transportConnect ion I VMO- coTransport Protocol LayerEntity 

1 

A. 5. 2. 2 

transportConnect ionRet ransmi ssi onl VMO- 
coTransportProtocolLayerEnt i  ty 

2 

B.3.3  Attribute  Object  Identifiers 

The  following  object  identifiers  are  assigned  under  the  {  y-attribute  }  node: 

Table  B.12  -  Object  identifiers  assigned  under  "y-attribute"  node 


Reference 

Identifier 

Value 

A. 5. 3.1 

transportConnect ion I VMO Id 

1 

B.3.4  Module  Object  Identifiers 

The  following  object  identifiers  are  assigned  under  the  {  y-module  }  node: 

Table  B.13  -  Object  identifiers  assigned  under  "y-module"  node 


Reference 

Identifier 

Value 

A. 5. 4 

SYNTAX-2 

1 
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Annex  C  (informative) 


MOCS  Proforma 

C.1  Introduction 

The  purpose  of  this  MOCS  proforma  is  to  provide  a  mechanism  for  a  supplier  of  an  implementation  of  these 
agreements  which  claims  conformance  to  a  managed  object  class  to  provide  conformance  information  in  a 
standard  form. 

C.2      Symbols,  abbreviations,  and  terms 

The  MOCS  proforma  contained  in  this  Annex  is  comprised  of  information  in  a  tabular  format  in  accordance  with 
the  guidelines  presented  in  ISO/IEC  96A6-2  [ATSS]  and  ISO/lEC  10165-6  tMICS]. 

The  following  conmon  notations,  defined  in  ISO/IEC  9646-2,  are  used  for  the  status  column. 

c  conditional 
m  mandatory 
o  opt { ona I 

X  prohibited 

not  applicable 

The  following  common  notations,  defined  in  ISO/IEC  9646-2,  are  used  for  the  support  column. 

Ig  the  item  is  ignored  (i.e.,  processed  syntactically  but  not  semantical ly) 

N  not  implemented 

Y  implemented 

not  applicable 

C.3      Instructions  for  completing  the  MOCS  proforma  to  produce  a  MOCS 

The  supplier  of  the  implementation  shall  enter  an  explicit  statement  in  each  of  the  boxes  provided  using  the 
notation  described  in  clause  C.2.    Additional  instructions  are  provided  in  ISO/IEC  10165-6,  Annex  B. 

C.4      Statements  of  Conformance  to  Managed  Object  Classes 


This  clause  contains  a  MOCS  Proforma  for  each  managed  object  class  defined  in  Annex  A  of  these  agreements, 
and  registered  by  Annex  B  of  these  agreements. 

C.4.1    Computer  System  MOCS  Proforma 


Managed  Object  class  template  label 

Value  of  Object  identifier  for  class 

"0P1  Library  Vol.  1":computerSystem 

{  1  3  14  2  2  1  1  > 

Are  all  mandatory  features  of  the  class  supported?  Yes   No_ 
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Table  C.4.1.1  >  Name  Binding  Support 


I  ndGX 

Mame  Rindlna  Temolato 
Label 

k/alue  of  Obiect 
Identifier  for 
Mame  Binding 

SuDerior  Obiect 
Class  Template 
Label 

Stat 
us 

Suppo 
rt 

Status 

Suppor 
t 

Addi tiona 
I 

Infomnti 
on 

c 
r 
e 
a 
t 
e 

d 
e 
I 
e 
t 
e 

c 
r 
e 
a 
t 
e 

d 
e 
I 
e 
t 
e 

C. 4. 1.1.1 

computerSystem- system 

C  1  3  14  2  2  3  1 
> 

"Rec.  X,721  j 
ISO/IEC  10165-2  : 
1992": system 

0 

n 

m 

C.4.1.1. 2 

computerSystem-opNetwork 

t  1  3  14  2  2  3  2 
) 

opNetwork 

° 

fn 

m 

C.4.1.1. 3 

computerSystem- 
computerSystem 

{  1  3  14  2  2  3  3 

} 

computerSystem 

0 

n 

m 

98 


PART  18:  Network  Management 


December  1992  (Stable) 


Table  C.4.1.2  -  Attribute  Support 


Index 

Attribute  Template  Label 

Value  of  Object 
Identifier  for 
Attribute 

Status 

Support 

Additional 
Informatio 
n 

s 
e 
t 
b 
y 

r 
e 
a 
t 
e 

9 
e 
t 

r 

e 

P 
I 
I 

a 
e 

a 
d 
d 

r 

e 
m 

0 
V 

Q 

s 
e 
t 
t 

0 

e 
f 
a 
u 
I 
t 

s 
e 
t 
b 

y 

Q 

r 
e 
a 
t 
e 

9 

e 
t 

r 
e 

P 
I 
a 

e 

3 

d 
d 

r 
e 
m 

0 
V 

Q 

s 
e 
t 
t 

0 

e 
f 
a 
u 
I 
t 

C. 4. 1.2.1 

peripheral  Name 

{  1  3  14  2  2  4  42 
) 

c3 

c3 

c3 

X 

X 

X 

C.4.1.2. 2 

peripheralList 

{  1  3  14  2  2  4  41 
> 

c4 

c4 

c4 

c4 

c4 

X 

C.4.1.2. 3 

process ingEnti  tyName 

{  1  3  14  2  2  4  44 
> 

c5 

c5 

c5 

X 

X 

X 

C.4.1.2. 4 

process  i  ngEnt  i  tyL  i  st 

{  1  3  14  2  2  4  43 
> 

c6 

c6 

c6 

c6 

c6 

X 

C.4.1.2. 5 

system! ime 

{  1  3  14  2  2  4  55 
> 

X 

cO 

X 

X 

X 

X 

C.4.1 .2.6 

1  mT  1  mo 

\JfJ  1   I  IMC 

V     1     J     1 H    C    ^    H  W 
> 

X 

cO 

X 

X 

X 

X 

C.4.1.2. 7 

"Rec.  M.3100  : 

1 00?(l  -  1  icon  1  ahol 

{  0  0  13  3100  0  7 

cO 

cO 

cO 

X 

X 

X 

C.4.1. 2. 8 

"Rec.  x.721   j  ISO/lEC 
iniA';-?  •  100?"- 

1 U  1  Oj  C   .    1  yyC  . 

usageState 

{29327  39} 

X 

c7 

X 

X 

X 

X 

C.4.1. 2. 9 

"Rec.  X.721   1  ISO/IEC 
10165-2  ■  1992"- 
operationalState 

{  2  9  3  2  7  35  } 

X 

m 

X 

X 

X 

X 

C.4.1. 2. 10 

"Rec.  X.721   1  ISO/IEC 
10165-2  :  1992": 
administrativeState 

{29327  31  } 

m 

m 

m 

X 

X 

X 

C.4.1. 2. 11 

"Rec.  X.721   I  ISO/IEC 
10165-2  :  1992": 
alarmStatus 

{29327  32} 

m 

m 

m 

m 

m 

X 

C.4.1. 2. 12 

"Rec.  X.721   j  ISO/IEC 
10165-2  :  1992": 
avai labi I i  tyStatus 

{29327  33  } 

X 

m 

X 

X 

X 

X 

C.4.1. 2. 13 

computerSystemId 

{  1  3  14  2  2  4  4 
} 

m 

m 

X 

X 

X 

X 

C.4.1. 2. 14 

"Rec.  X.721   j  ISO/lEC 
10165-2  :  1992": 
a  I lomorphs 

{29327  50} 

Cl 

cl 

X 

X 

X 

X 

C.4.1. 2. 15 

"Rec.  X.721   1  ISO/IEC 
10165-2  :  1992": 
nameBinding 

{29327  63  } 

m 

m 

X 

X 

X 

X 

C.4.1. 2. 16 

"Rec.  X.721   1  ISO/IEC 
10165-2  :  1992": 
objectClass 

{29327  65  } 

0(1 

m 

X 

X 

X 

X 

C.4.1. 2. 17 

"Rec.  X.721  j  ISO/IEC 
10165-2  :  1992": 
packages 

{29327  66} 

c2 

c2 

X 

X 

X 

X 

cO  =  m  if  an  instance  supports  it,  else  - 

cl  =  m  if  an  object  supports  al lormorphism,  else  - 

c2  =  m  if  any  any  registered  package  (other  than  this  package)  has  been  instantiated,  else 
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c3  s  m  if  an  instance  supports  it  and  the  peripheralListPkg  is  NOT  present,  else  x 
c4  =  m  if  an  instance  supports  it  and  the  peripheralNamePkg  is  NOT  present,  else  x 
c5  =  m  if  an  instance  supports  it  and  the  process ingEntityListPkg  is  NOT  present,  else  x 
c6  =  m  if  an  instance  supports  it  and  the  process ingEntityNamePkg  is  NOT  present,  else  x 
c7  ~  m  if  a  resource  can  detect  usage,  else  - 
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Table  C.4.1.3  -  Attribute  Group  Support 


Index 

Attribute  Group  Teinplate  Label 

Value  of  Object 

Status 

Suppor 

Additional  Information 

Identifier  for 

t 

Attribute  Group 

9 

s 

9 

8 

e 

e 

e 

e 

t 

t 

t 

t 

t 

t 

0 

0 

d 

d 

e 

e 

f 

f 

a 

a 

u 

u 

I 

I 

t 

t 

C. 4. 1.3.1 

"Rec.  X.721  1  ISO/lEC  10165-2  : 

{293281} 

m 

X 

1992":state 

101 


PART  18:  Network  Management 


December  1992  (Stable) 


Table  C.4.1.5  -  Notification  Support 


Index 

Notification 
Type  Label 

Value  of 
Notif icatio 
n  Type 
I  dent  i  f  i  er 

Stat 
us 

Suppor 
t 

Add 
Info 

Sub- 
I  ndcx 

Notification 

P  1  o  1  H  IJ  AfnA 
r  1  c L u  nciiiic 

Label 

Value  of 
Type 

associated 
with  Field 

Stat 

us 

Suppo 

Addition 

al 

Informat 
ion 

c 

0 

n 
f 

n 

0 

n 

C. 4. 1.5.1 

"Rec.  X.721  1 
ISO/IEC  10165-2 
:  1992": 
attributeValueC 
hange 

C  2  9  3  2 
10  1  > 

m 

C.4.1 
.5.1. 
1 

additional  Info 
rmation 

{  2  9  3  2  7 
6  } 

0 

C.4.1 
.5.1. 

2 

addi  tionalText 

{  2  9  3  2  7 
7  > 

0 

C.4.1 
.5.1. 

3 

attributeldent 
if ierList 

{  2  9  3  2  7 
8  > 

0 

C.4.1 
.5.1. 

4 

attributeValue 
ChangeDef initi 
on 

{  2  9  3  2  7 
10  } 

n 

C.4.1 
.5.1. 

5 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  } 

0 

C.4.1 
.5.1. 

6 

notif icationid 
entif ier 

{  2  9  3  2  7 
16  } 

0 

C.4.1 
.5.1. 

7 

sourcelndicato 
r 

{  2  9  3  2  7 
26  > 

0 

C.A.I. 5. 2 

"Rec.  X.721  1 
ISO/IEC  10165-2 
:  1992": 
objectCreation 

C  2  9  3  2 
10  6  > 

m 

C.4.1 
.5.2. 

1 

additional  Info 
rmation 

{  2  9  3  2  7 
6  > 

0 

C.4.1 
.5.2. 

2 

additionalText 

{  2  9  3  2  7 
7  ) 

0 

C.4.1 
.5.2. 

3 

attributeList 

{  2  9  3  2  7 
9  > 

0 

— — — — 

C.4.1 
.5.2. 

4 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  } 

0 

C.4.1 
.5.2. 

5 

notif icationid 
entif ier 

{  2  9  3  2  7 
16  } 

0 

C.4.1 
.5.2. 

6 

sourcelndicato 
r 

{  2  9  3  2  7 

26  > 

0 

 . — 

C.4.1.5. 3 

"Rec.  X.721  j 
ISO/IEC  10165-2 
:  1992": 
objectDeletion 

{  2  9  3  2 
10  7  > 

m 

C.4.1 
.5.3. 
1 

additional  Info 
rmation 

{  2  9  3  2  7 
6  } 

0 

C.4.1 
.5.3. 
2 

additionalText 

{  2  9  3  2  7 
7  > 

0 

C.4.1 
.5.3. 

3 

attributeList 

{  2  9  3  2  7 
9  > 

0 

C.4.1 
.5.3. 

4 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.1 
.5.3. 

5 

notif icationid 
entif ier 

{  2  9  3  2  7 
16  } 

0 
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Stat  ISuppo  {Addition 


llndex 


Notification 
Type  Label 


Value  of 
Notif icatio 

Type 
Identifier 


Stat 
us 


Suppor 


^dd 
Info 


Sub-  Not  i  f  i  cat  i  on 
Index  Field  Name 
Label 


Value  of 
OID  of  Attn 
Type 

associated 
with  Field 


LIS 


rt 


al 

Infonaat 

ion 


"Rec.  X.721  ' 


IC.4.1 
5.3. 

16 


sourcelndicato 
r 


{  2  9  3  2  7 
26  > 


C.4. 1.5.4 


ISO/IEC  10165 

1992": 
stateChange 


-210 


(  2  9  3  2 
14  > 


T 


IC.4.1 
5.4. 

1 


additional Info 
rmation 


C  2  9  3  2  7 
|6  > 


p. 4.1 
.5.4. 
12 


additional Text 


{  2  9  3  2  7 
7  > 


iC.4.1 
5.4. 

3 


attributeldent 
if ierList 


{29327 
|8  > 


t.4.1 
5.4. 

14 


correlatedNoti 
fi cat  ions 


{  2  9  3  2  7 
12  > 


p. 4.1 
5.4. 

5 


notif icationld 
ent  i  f  i  er 


{  2  9  3  2  7 
16  > 


p. 4.1 
5.4. 

16 


sourcelndicato 
r 


{  2  9  3  2  7 
26  > 


t.4.1 
5.4. 

17 


stateChangeDef 
ini  tion 


{  2  9  3  2  7 
28  > 


C. 4. 1.5. 5 


"Rec.  X.721 


ISO/IEC  10165 
:  1992": 
processingError 
Alarm 


{  2  9  3  2 
10  > 


210 


IC.4.1 
5.5. 

1 


additional  Info 
rmation 


{  2  9  3  2  7|o 
6  > 


IC.4.1 
5.5. 

12 


additionalText 


{  2  9  3  2  7 
7  > 


IC.4.1 
.5.5. 
13 


backUpObject 


{  2  9  3  2  7 
41  > 


IC.4.1 
5.5. 

14 


backedUpStatus 


{  2  9  3  2  7 
11  > 


IC.4.1 
5.5. 

15 


correlatedNoti 
fi cat  ions 


{  2  9  3  2  7 
12  > 


IC.4.1 
5.5. 

16 


notif icationld 
entif ier 


{  2  9  3  2  7 
16  > 


IC.4.1 
.5.5. 
17 


perceivedSever 
ity 


{  2  9  3  2  7h 
17  > 


IC.4.1 
.5.5. 
18 


probableCause 


{  2  9  3  2  7|m 
18  > 


IC.4.1 
5.5. 

19 


proposedRepair 
Actions 


{  2  9  3  2  7|o 
19  > 


IC.4.1 
.5.5. 
10 


specif icProble 

IDS 


{  2  9  3  2  7|o 
27  > 


IC.4.1 
5.5. 
11 


StateChangeDef 
ini tion 


{  2  9  3  2  7 
28  > 
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Index 

Notification 
Type  Label 

Value  of 
Notif icatio 
n  Type 
I  dent  i  f  i  er 

Stat 
us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

Notification 
Field  Name 
Label 

Value  of 
OID  of  Attr 
Type 

associated 
with  Field 

Stat 

LIS 

Suppo 
rt 

Addition 
al 

Informal 
ion 

c 

0 

n 
f 

n 

0 

n 

C.4.1 
.5.5. 

12 

thresholdlnfo 

{  2  9  3  2  7 
29  > 

0 

C.4.1 
.5.5. 
13 

trendlndicatio 
n 

{  2  9  3  2  7 
30  > 

0 

C.4.1. 5. 6 

j    ■     ,  ■' 

"Rec.  X.721  1 
ISO/IEC  10165-2 
:  1992": 
environmentalAl 
arm 

{  2  9  3  2 
10  3  > 

m 

C.4.1 
.5.6. 

1 
1 

additional  Info 
rmation 

{  2  9  3  2  7 
6  > 

0 

C.4.1 
.5.6. 

C 

additionalText 

{  2  9  3  2  7 
7  > 

0 

C.4.1 
.5.6. 

i 

backUpObject 

{  2  9  3  2  7 
41  > 

0 

C.4.1 
.5.6. 

/. 
H 

backedUpStatus 

{  2  9  3  2  7 
11  > 

0 

C.4.1 
.5.6. 

5 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.1 
.5.6. 

6 

notif icationid 
entif ier 

{  2  9  3  2  7 
16  > 

0 

C.4.1 
.5.6. 

7 

perceivedSever 
ity 

{  2  9  3  2  7 
17  > 

m 

C.4.1 
.5.6. 

8 

probableCause 

{  2  9  3  2  7 
18  > 

in 

C.4.1 
.5.6. 

9 

proposedRepair 
Actions 

{  2  9  3  2  7 
19  > 

0 

C.4.1 
.5.6. 

1  u 

specif icP rob I e 
ms 

{  2  9  3  2  7 
27  ) 

0 

c.4.1 
.5.6. 

1 1 
1 1 

stateChangeDef 
i nit  ion 

{  2  9  3  2  7 
28  > 

0 

C.4.1 
.5.6. 

12 

thresholdlnfo 

{  2  9  3  2  7 
29  > 

0 

C.4.1 
.5.6. 
13 

trendlndicatio 
n 

{  2  9  3  2  7 
30  > 

0 

C. 4, 1.5. 7 

"Rec.  X.721  1 
ISO/IEC  10165-2 
:  1992": 
equipmentAlarm 

{  2  9  3  2 
10  4  } 

ID 

C.4.1 
.5.7. 

1 

additional  Info 
rmation 

{  2  9  3  2  7 
6  > 

0 

C.4.1 
.5.7. 

2 

addi  tionalText 

{  2  9  3  2  7 
7  > 

0 

C.4.1 
.5.7. 
3 

backUpObject 

{  2  9  3  2  7 
41  > 

0 

C.4.1 
.5.7. 

4 

backedUpStatus 

{  2  9  3  2  7 
11  > 

0 
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Index 

Not  i  f  i  cat  i  on 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 
us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

Notification 
Field  Name 
Label 

Value  of 
OID  of  Attr 
TvDe 

associated 
with  Field 

Stat 
us 

Suppo 
rt 

Addition 
al 

Inf  ortnat 
ion 

c 

0 

n 
f 

n 

0 

n 

C.4.1 
.5.7. 

5 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.1 
.5.7. 

6 

notif icationid 
ent  i  f  i  er 

C  2  9  3  2  7 
16  > 

0 

C.4.1 
.5.7. 

7 

percei vedSever 
ity 

{  2  9  3  2  7 
17  > 

ID 

C.4.1 
.5.7. 

8 

probableCause 

C  2  9  3  2  7 
18  > 

ID 

C.4.1 
.5.7. 

9 

proposedRepai  r 
Actions 

C  2  9  3  2  7 
19  > 

0 

C.4.1 
.5.7. 

10 

specif icP rob le 
ms 

C  2  9  3  2  7 
27  ) 

0 

C.4.1 
.5.7. 

11 

stateChangeDef 
ini  tion 

{  2  9  3  2  7 
28  > 

0 

C.4.1 
.5.7. 
12 

thresholdlnfo 

{  2  9  3  2  7 
29  > 

0 

C.4.1 
.5.7. 

13 

trendlndicatio 
n 

{  2  9  3  2  7 
30  > 

0 

C.4.2    Connection  Oriented  Transport  Protocol  Layer  Entity  MOCS  Proforma 


Managed  Object  class  template  label 

Value  of  Object  identifier  for  class 

"0P1  Library  Vol. 
1":coTransportProtocolLayerEntity 

{  1  3  14  2  2  1  2  > 

Are  all  mandatory  features  of  the  class  supported?  Yes   No 


Table  C.4.2.1  -  Name  Binding  Support 


Index 

Name  Binding  Template 

Value  of  Object 

Superior  Object 

Stat 

Suppo 

Status 

Suppor 

Addi  tiona 

Label 

Identifier  for 

Class  Template 

us 

rt 

t 

I 

Name  Binding 

Label 

c 

d 

c 

d 

Informati 

r 

e 

r 

e 

on 

e 

I 

e 

I 

a 

e 

a 

e 

t 

t 

t 

t 

e 

e 

e 

e 

C.4.2. 1.1 

coTransportProtocol Layer 

{  1  3  14  2  2  3  4 

computerSystem 

0 

X 

X 

Enti ty-computerSystem 

> 

C.4.2. 1.2 

coTransportProtocol Layer 

{  1  3  14  2  2  3  5 

"Rec.  X.721  I 

0 

x 

X 

Ent ity- system 

> 

ISO/IEC  10165-2  : 

1992": system 

C.4.2. 1.3 

coTransportProtocol Layer 

{  1  3  14  2  2  3  6 

opEquipfnent 

0 

X 

X 

Ent  i  ty- opEqui  pment 

> 
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Table  C.4.2.2  -  Attribute  Support 


Index 

Attribute  Template  Label 

Value  of  Object 
Identifier  for 
Attribute 

Status 

Support 

Additional 
Informatio 
n 

s 
e 
t 
b 

y 

c 
r 
e 
a 
t 
e 

g 

e 
t 

r 
e 

P 
I 
a 
c 
e 

a 
d 
d 

r 
e 
m 

0 
V 

e 

s 
e 
t 
t 

0 

d 
e 
f 
a 
u 
I 
t 

s 
e 
t 
b 

y 

c 
r 
e 
a 
t 
e 

g 

e 
t 

r 
e 

P 
I 
a 
c 
e 

a 
d 
d 

r 
e 

in 

0 
V 

e 

s 
e 
t 
t 

0 

d 
e 
f 
a 
u 
I 
t 

C.4.2.2. 1 

manufacturerList 

{  1  3  14  2  2  4  23 
> 

c3 

c3 

c3 

c3 

c3 

C.A.2.2.2 

manuf acturerName 

C  1  3  14  2  2  4  24 
> 

c4 

c4 

c4 

X 

X 

X 

C.4.2.2. 3 

productLabel 

{  1  3  14  2  2  4  45 
> 

cO 

cO 

cO 

X 

X 

X 

C.4.2.2. 4 

"Rec.  M.3100  : 
1992": vers ion 

C  0  0  13  3100  0  7 
52  > 

cO 

cO 

cO 

X 

X 

X 

C.4.2.2. 5 

serialNumber 

{  1  3  14  2  2  4  50 
> 

cO 

cO 

cO 

X 

X 

X 

C.4.2.2. 6 

type! ex t 

C  1  3  14  2  2  4  59 
> 

cO 

cO 

cO 

X 

X 

X 

C.4.2.2. 7 

upT  i  ine 

{  1  3  14  2  2  4  60 
> 

X 

cO 

X 

X 

X 

X 

C.4.2.2. 8 

"Rec.  X.721  }  ISO/IEC 
10165-2  :  1992": 
incomingProtocolErrorCount 
er 

<:29327  77  } 

X 

cO 

X 

X 

X 

X 

C.4.2.2. 9 

"Rec.  X.721  I  ISO/IEC 
10165-2  :  1992": 
outgoingProtocolErrorCount 
er 

{29327  85} 

X 

cO 

X 

X 

X 

X 

C.4.2.2. 10 

checksumPDUsD  i  scardedCount 
er 

{  1  3  14  2  2  4  3 
} 

X 

cO 

X 

X 

X 

X 

C.4.2.2. 11 

maxPDUSize 

C  1  3  14  2  2  4  26 
} 

c5 

c5 

c5 

X 

X 

X 

C.4.2.2. 12 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
usageState 

{;29327  39  } 

X 

c6 

X 

X 

X 

X 

C.4.2.2. 13 

transportEnti  tyType 

C  1  3  14  2  2  4  58 
} 

X 

m 

X 

X 

X 

X 

C.4.2.2. 14 

I  oca  I T  ransport Addresses 

{  1  3  14  2  2  4  20 
} 

X 

m 

X 

X 

X 

X 

C.4.2.2. 15 

ac t  i  veConnec  t  i  ons 

{  1  3  14  2  2  4  1 
} 

X 

m 

X 

X 

X 

X 

C.4.2.2. 16 

maxConnections 

{  1  3  14  2  2  4  25 
} 

X 

m 

X 

X 

X 

X 

C.4.2.2. 17 

"Rec.  X.721  j  ISO/IEC 
10165-2  :  1992": 
outgoingConnect  i  onRequests 
Counter 

{29327  82} 

X 

m 

X 

X 

X 

X 

C.4.2.2. 18 

"Rec.  X.721   1  ISO/IEC 

10165-2  :  1992": 

incomi  ngConnect  i  onRequests 

Counter 

{29327  74  } 

X 

m 

X 

X 

X 

X 
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Index 

Attribute  Template  Label 

Value  of  Object 
Identifier  for 
Attribute 

Status 

Support 

Add  i  t  i  ona I 
Informatio 
n 

s 
e 
t 
b 
y 
c 
r 
e 
a 
t 
e 

a 
e 
t 

r 
e 

P 
I 
a 
c 
e 

a 
d 
d 

r 
e 

m 

0 
V 

e 

s 
e 
t 
t 

0 

d 
e 
f 
a 
u 
I 
t 

e 
t 
b 
y 
c 
r 
e 
a 
t 
e 

a 
e 
t 

r 
e 
P 
I 
a 
c 
e 

3 

d 
d 

e 

m 

0 
V 

e 

e 
t 
t 

0 

d 
e 
f 
a 
u 
I 
t 

C. 4. 2. 2. 19 

"Rec.  X.721  1  I  SO/ 1  EC 

10165-2  :  1992": 

out  go 1 ngConnec  t  i  onR  e  j  ec  t E  r 

rorCounter 

{29327  81  > 

m 

C. 4. 2. 2. 20 

"Rec.  X.721  1  I  SO/ 1  EC 

10165-2  :  1992": 

i  ncomi  ngConnect  i  onRe  j  ectEr 

rorCounter 

{  2  9  3  2  7  73  > 

X 

m 

X 

X 

X 

X 

u. 4. 2. 2. 21 

"Rec.  A.fdi  I  iso/itc 

10165-2  :  1992": 

outgoi  ngD  i  sconnectE  rrorCou 

nter 

X 

m 

X 

X 

X 

X 

C. 4. 2. 2. 22 

"Rec.  X.721  1  ISO/IEC 

10165-2  :  1992": 

1  ncodii  ng0 1  sconnectE  rrorCou 

nter 

{  2  9  3  2  7  76  > 

X 

m 

X 

X 

X 

X 

C, 4. 2. 2. 23 

"Rec.  X.721  1  ISO/IEC 
outgoi  ngD  i  sconnectCounter 

{29327  83  } 

X 

m 

X 

X 

X 

X 

C. 4. 2. 2. 24 

"Rec.  X.721  !  ISO/IEC 
iniAS-7  •  1007*>> 

i  ncomi  ngD  i  sconnectCounter 

{29327  75  } 

X 

m 

X 

X 

X 

X 

C. 4. 2. 2. 25 

"Rec.  X.721  1  ISO/IEC 
octetsSentCounter 

{  2  9  3  2  7  80  } 

X 

m 

X 

X 

X 

X 

C. 4. 2. 2. 26 

"Rec.  X.721  j  ISO/IEC 
10165-2  :  1992": 
octetsReceivedCounter 

(29327  78  } 

X 

m 

X 

X 

X 

X 

C. 4. 2. 2. 27 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
operational  State 

{29327  35} 

X 

m 

X 

X 

X 

X 

C. 4. 2. 2. 28 

"Rec.  X.721  j  ISO/IEC 
10165-2  :  1992": 
administrati veState 

{29327  31  } 

m 

m 

in 

X 

X 

X 

C. 4. 2. 2. 29 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
alarmStatus 

{29327  32} 

m 

m 

m 

m 

m 

X 

C. 4. 2. 2. 30 

coTransportProtocol Layer  Id 

{  1  3  14  2  2  4  6 
} 

m 

m 

X 

X 

X 

X 

C. 4. 2. 2. 31 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
al lomorphs 

{  2  9  3  2  7  50  } 

c1 

c1 

X 

X 

X 

X 

C. 4. 2. 2. 32 

"Rec,  X.721  1  ISO/IEC 
10165-2  :  1992": 
nameBinding 

{29327  63  } 

m 

m 

X 

X 

X 

X 

C. 4. 2. 2. 33 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
objectClass 

{29327  65  } 

m 

m 

X 

X 

X 

X 

C. 4. 2. 2. 34 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
packages 

{2932766} 

c2 

c2 

X 

X 

X 

X 
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cO  =  m  if  an  instance  supports  it,  else  - 

c1  =  m  if  an  object  supports  al lormorphism,  else  - 

c2  =  m  if  any  any  registered  package  (other  than  this  package)  has  been  instantiated,  else  - 

c3  =  m  if  an  instance  supports  it  and  the  manufacturerNamePkg  is  NOT  present,  else  x 

c4  -  m  if  an  instance  supports  it  and  the  manufacturerListPkg  is  NOT  present,  else  x 

c5  =  m  if  the  "OPI  Library  Vol.  2  :  1992":transportConnectionIVM0  object  class  is  not  used  to 
provide  this  initial  value,  else  x 

c6  =  m  if  resource  can  detect  usage,  else  - 


Table  C.4.2.3  -  Attribute  Group  Support 


Index 

Attribute  Group  Teniplate  Label 

Value  of  Object 

Status 

Suppor 

Additional  Information 

Identifier  for 

t 

Attribute  Group 

9 

s 

9 

s 

e 

e 

e 

e 

t 

t 

t 

t 

t 

t 

0 

0 

d 

d 

e 

e 

f 

f 

a 

a 

u 

u 

I 

I 

t 

t 

C.4.2.3. 1 

"Rec.  X.721  1  ISO/IEC  10165-2  : 

{  2  9  3  2  8  1  } 

m 

X 

1992":state 
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Table  C.4.2.5  -  Notification  Support 


Index 

Notification 
Type  Laisel 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 
us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

Field  Name  Label 

V/a  1 1  lA 
V  a  I w 1 

OID  of  Attr 
Type 

associated 
with  Field 

Stat 
us 

Suppo 
rt 

Addi  t 
ional 
Infor 
nnatio 
n 

c 

0 

n 
f 

n 

0 

n 

C.4.2.5. 1 

"Rec.  X.721  1 
ISO/IEC  10165-2 
:  1992": 
attributeValueC 
hange 

€  2  9  3  2 
10  1  > 

m 

C.4.2 
.5.1. 

1 

addi  t  i ona 1 1 nf  orro 
at  ion 

{  2  9  3  2  7 
6  > 

0 

C.4.2 
.5.1. 

2 

additional  Text 

{  2  9  3  2  7 
7  > 

0 

C,4.2 
.5.1. 

3 

attributeldentif 
ierList 

{  2  9  3  2  7 
8  > 

0 

C.4.2 
.5.1. 

4 

attributeValueCh 
angeDef inition 

{  2  9  3  2  7 
10  > 

m 

C.4.2 
.5.1. 

5 

correlatedNotif i 
cations 

{  2  9  3  2  7 
12  > 

0 

C.4.2 
.5.1. 

6 

notif icationlden 
ti  f ier 

{  2  9  3  2  7 
16  } 

0 

C.4.2 
.5.1. 

7 

sourcelndicator 

{  2  9  3  2  7 
26  > 

0 

C.4.2.5. 2 

"Rec.  X.721  j 
ISO/IEC  10165-2 
:  1992": 
objectCreation 

<:  2  9  3  2 
10  6  > 

m 

C.4.2 
.5.2. 
1 

addi  ti ona I  Inform 
at  ion 

{  2  9  3  2  7 
6  > 

0 

C.4.2 
.5.2. 

2 

addi  tionalText 

{  2  9  3  2  7 
7  > 

0 

C.4.2 
.5.2. 
3 

attr ibuteList 

{  2  9  3  2  7 
9  > 

0 

C.4.2 
.5.2. 

4 

correlatedNotif i 
cations 

{  2  9  3  2  7 
12  > 

0 

C.4.2 
.5.2. 

5 

notif icationlden 
tif ier 

{  2  9  3  2  7 
16  > 

0 

C.4.2 
.5.2. 

6 

sourcelndicator 

{  2  9  3  2  7 
26  > 

0 

C.4.2.5, 3 

"Rec.  X.721  j 
ISO/IEC  10165-2 
:  1992": 
objectDeletion 

{  2  9  3  2 
10  7  ) 

m 

C.4.2 
.5.3. 
1 

add  i  t  i  ona  1 1  nf  orm 
at  ion 

{  2  9  3  2  7 
6  } 

0 

C.4,2 
.5.3. 

2 

addi tionalText 

{  2  9  3  2  7 
7  > 

0 

C.4.2 
.5.3. 

3 

attributeList 

{  2  9  3  2  7 
9  } 

0 

C.4.2 
.5.3. 

4 

correlatedNotif! 
cations 

{  2  9  3  2  7 
12  } 

0 

C.4.2 
.5.3. 

5 

notif icationlden 
tif ier 

{  2  9  3  2  7 
16  } 

0 
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Index 

Not  i  f  i  cat  i  on 
Type  Label 

Value  of 
Not  i  f  i  cat  i  o 
n  Type 
Identifier 

Stat 
us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

Noti  f ication 
Field  Name  Label 

Value  of 
OID  of  Attr 
Type 

associated 
with  Field 

Stat 

us 

Suppo 
rt 

Addit 
ional 
Infer 
matio 
n 

c 
o 

n 
f 

n 

0 

n 

C.4.2 
.5.3. 

sourcelndicator 

{  2  9  3  2  7 
26  > 

0 

C.4.2.5.4 

"Rec.  X.721  1 
ISO/IEC  10165-2 
:  1992": 
stateChange 

t 

{  2  9  3  2 
10  14  > 

m 

C.4.2 
.5.4. 
1 

addi  tional Inform 
at  ion 

{  2  9  3  2  7 
6  > 

0 

C.4.2 

.5.4. 
2 

addi  tionalText 

{  2  9  3  2  7 

7  > 

0 

C.4.2 
.5.4. 

z 
J 

attributeldentif 
ierList 

{  2  9  3  2  7 
8  > 

0 

C.4.2 
.5.4. 

correlatedNotif i 
cations 

{  2  9  3  2  7 
12  > 

° 

C.4.2 

.5.4. 

notif icationlden 
t  i  f  i  er 

{  2  9  3  2  7 
16  > 

o 

C.4.2 
.5.4. 

sourcelndicator 

{  2  9  3  2  7 
26  ) 

0 

C.4.2 
.5.4. 

7 

stateChangeDef in 
i  t  i  on 

{  2  9  3  2  7 

28  > 

m 

C.4.2.5.5 

"Rec.  X.721  1 
ISO/IEC  10165-2 
:  1992": 
process ingError 
Alarm 

{  2  9  3  2 
10  10  > 

m 

cXI 

.5.5. 
1 

addi tional Inform 
at  ion 

{  2  9  3  2  7 
6  > 

0 

C.4.2 
.5.5. 
2 

addi tional Text 

{  2  9  3  2  7 
7  > 

0 

C.4.2 

.5.5. 

J 

backUpObject 

{  2  9  3  2  7 

41  > 

0 

C.4.2 
.5.5. 

backedUpStatus 

{  2  9  3  2  7 
11  > 

0 

C.4.2 
.5.5. 

5 

correlatedNotif i 
cations 

{  2  9  3  2  7 
12  > 

0 

C.4.2 
.5.5. 

6 

notif icationlden 
t  i  f  i  er 

{  2  9  3  2  7 
16  > 

0 

C.4.2 
.5.5. 

( 

perceivedSeveri t 

y 

{  2  9  3  2  7 
17  > 

ID 

C.4.2 
.5.5. 

8 

probableCause 

{  2  9  3  2  7 
18  > 

m 

C.4.2 
.5.5. 

9 

proposedRepa  i  rAc 
t  i  ons 

{  2  9  3  2  7 
19  > 

0 

C.4.2 
.5.5. 
10 

specif icP rob I  ems 

{  2  9  3  2  7 
27  > 

0 

C.4.2 
.5.5. 
11 

StateChangeDef in 
i  tion 

{  2  9  3  2  7 
28  > 

0 

L_ 
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Index 

Notification 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 
us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

Noti  f ication 
Field  Name  Label 

Value  of 
OID  of  Attr 
Type 

associated 
with  Field 

Stat 
us 

Suppo 
rt 

Addit 
ional 
Infor 
matio 
n 

c 

0 

n 
f 

n 

0 

n 

C.4.2 
.5.5. 
12 

thresholdlnfo 

(  2  9  3  2  7 
29  } 

0 

C.4.2 
.5.5. 

13 

trendlndication 

{  2  9  3  2  7 
30  } 

0 

C.4.3    ConnectionlessNetwork  Protocol  Layer  Entity  MOCS  Proforma 


Managed  Object  class  template  label 

Value  of  Object  identifier  for  class 

"0P1  Library  Vol.  1":clNetworkProtocolLayerEntity 

{  1  3  14  2  2  1  3  > 

Are  all  mandatory  features  of  the  class  supported?  Yes   No 


Table  C.4.3. 1  -  Name  Binding  Support 


Index 

Name  Binding  Template 

Value  of  Object 

Superior  Object 

Stat 

Suppo 

Status 

Suppor 

Addition 

Label 

Identifier  for 

Class  Template 

us 

rt 

t 

al 

Name  Binding 

Label 

c 

d 

c 

d 

Informal 

r 

e 

r 

e 

ion 

e 

I 

e 

I 

a 

e 

a 

e 

t 

t 

t 

t 

e 

e 

e 

e 

C.4.3. 1.1 

clNetworkProtocolLayerEnt 

{  1  3  14  2  2  3  7 

computerSystem 

0 

X 

X 

i  ty-computerSystem 

> 

C.4.3. 1.2 

ClNetworkProtocolLayerEnt 

C  1  3  14  2  2  3  8 

"Rec.  X.721  1 

0 

X 

X 

ity- system 

> 

ISO/IEC  10165-2  : 

1992": system 

C.4.3. 1.3 

ClNetworkProtocolLayerEnt 

{  1  3  14  2  2  3  9 

opEquipment 

0 

X 

X 

i  ty-opEquipment 

} 
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Table  C. 4.3.2  -  Attribute  Support 
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Index 

Attribute  Template  Label 

Value  of  Object 
Identifier  for 
Attribute 

Status 

Support 

Additiona 
I 

Informati 
on 

g 

e 
t 
b 
y 

c 
r 
e 
a 
t 
e 

n 
9 

e 
t 

p 

e 

P 
I 

a 
c 
e 

d 
d 

p 

e 
m 

0 
V 

e 

g 

e 
t 
t 

0 

d 
e 
f 
a 
u 
I 
t 

c 

e 
t 

b 

y 

c 
r 
e 
a 
t 
e 

9 
e 
t 

r 
e 

P 

I 

a 
c 
e 

9 

d 
d 

r 
e 

m 

0 

e 

s 
e 
t 
t 

0 

d 
e 
f 
a 
u 
I 
t 

C. 4. 3. 2. 21 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
alarmStatus 

{:29327  32  } 

m 

m 

m 

m 

m 

X 

C. 4. 3. 2. 22 

clNetworkProtocolLayerld 

m 

m 

X 

X 

X 

X 

C. 4. 3. 2. 23 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
al lomorphs 

<:29327  50  } 

c1 

c1 

X 

X 

X 

X 

C. 4. 3. 2. 24 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
natneBinding 

<:29327  63  > 

m 

m 

X 

X 

X 

X 

C. 4. 3, 2. 25 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
objectClass 

<;29327  65  > 

m 

m 

X 

X 

X 

X 

C. 4. 3. 2. 26 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
packages 

<:29327  66  > 

c2 

c2 

X 

X 

X 

X 

cO  =  m  if  an  instance  supports  it,  else  - 

c1  =  m  if  an  object  supports  al lormorphism,  else  - 

c2  =  m  if  any  any  registered  package  (other  than  this  package)  has  been  instantiated,  else 
c3  =  m  if  an  instance  supports  it  and  the  manufacturerNamePkg  is  NOT  present,  else  x 
c4  =  m  if  an  instance  supports  it  and  the  manufacturerListPkg  is  NOT  present,  else  x 
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Table  C.4.3.3  -  Attribute  Group  Support 


Index 

Attribute  Group  Template  Label 

Value  of  Object 
Identifier  for 

Status 

Suppor 
t 

Additional  Information 

Attribute  Group 

9 

s 

9 

s 

e 

e 

e 

e 

t 

t 

t 

t 

t 

t 

0 

0 

d 

d 

e 

e 

f 

f 

a 

a 

u 

u 

I 

I 

t 

t 

C.4.3.3. 1 

"Rec.  X.721  j  ISO/IEC  10165-2  : 
1992":state 

C  2  9  3  2  8  1  > 

m 

X 
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Table  C.4.3.5  -  Notification  Support 


Index 

Notification 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 
us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

Notification 
Field  Name 
Label 

Value  of 
OID  of  Attr 

associated 
with  Field 

Stat 

us 

Suppo 
rt 

Addition 
al 

1 1 1 1  Ul  MO  L 

ion 

c 

0 

n 
f 

n 

0 

n 

C.4.3.5. 1 

"Rec.  X.721  1 
ISO/IEC  10165-2 
:  1992": 
attributeValueC 
hange 

{  2  9  3  2 
10  1  > 

m 

C.4.3 
.5.1. 
1 

additional  Info 
rmation 

{  2  9  3  2  7 
6  > 

0 

C.4.3 
.5.1. 

2 

additional Text 

€29327 
7  > 

0 

C.4.3 
.5.1. 
3 

attributeldent 
if ierList 

{  2  9  3  2  7 
8  > 

0 

C.4.3 
.5.1. 

4 

attributeValue 
ChangeDef initi 
on 

{29327 
10  > 

m 

C.4.3 
.5.1. 

5 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.3 
.5.1. 

6 

notif icationid 
entif ier 

{  2  9  3  2  7 
16  > 

0 

C.4.3 
.5.1. 

7 

sourcelndicato 
r 

{  2  9  3  2  7 
26  > 

0 

C.4.3.5. 2 

"Rec.  X.721  1 
ISO/IEC  10165-2 
:  1992": 

objectCreation 

(  2  9  3  2 
10  6  } 

m 

C.4.3 
.5.2. 
1 

additional  Info 
rmat  i  on 

{  2  9  3  2  7 
6  > 

o 

C.4.3 
.5.2. 

2 

addi  tionalText 

{  2  9  3  2  7 
7  > 

0 

C.4.3 
.5.2. 
3 

attributeList 

{  2  9  3  2  7 
9  } 

0 

C.4.3 
.5.2. 

4 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.3 
.5.2. 

5 

notif icationid 
entif ier 

{  2  9  3  2  7 
16  ) 

0 

C.4.3 
.5.2. 

6 

sourcelndicato 
r 

{  2  9  3  2  7 
26  > 

0 

C.4.3.5. 3 

"Rec.  X.721  1 
ISO/IEC  10165-2 
:  1992": 
objectDeletion 

C  2  9  3  2 
10  7  } 

ID 

C.4.3 
.5.3. 
1 

additional  Info 
rmat  i  on 

{  2  9  3  2  7 
6  > 

0 

C.4.3 
.5.3. 

2 

addi tionalText 

{  2  9  3  2  7 
7  > 

0 

C.4.3 
.5.3. 

3 

attributeList 

{  2  9  3  2  7 
9  > 

0 

C.4.3 
.5.3. 

4 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  } 

0 
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Index 

Notification 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identi  f ier 

Stat 
us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

Notification 
Field  Name 
Label 

Value  of 
OID  of  Attr 
TvDe 

associated 
with  Field 

Stat 
us 

Suppo 
rt 

Addition 
al 

Inf ormat 
ion 

c 

0 

n 
f 

n 

0 

n 

C.4.3 
.5.3. 

5 

notif icationid 
ent  i  f  i  er 

{  2  9  3  2  7 
16  > 

0 

C.4.3 
.5.3. 

6 

sourcelndicato 
r 

{  2  9  3  2  7 
26  > 

0 

C.4.3. 5. 4 

"Rec.  X.721  1 
ISO/IEC  10165-2 
:  1992": 
stateChange 

{  2  9  3  2 
10  K  > 

m 

C.4.3 
.5.4, 
1 

addi  tional Info 
rmation 

{  2  9  3  2  7 
6  > 

0 

C.4.3 
.5.4. 

2 

addi  tionalText 

{  2  9  3  2  7 
7  > 

o 

C.4.3 
.5.4. 

3 

attribute Ident 
if ierList 

{  2  9  3  2  7 
8  > 

o 

C.4.3 
.5.4. 

4 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.3 
.5.4. 

5 

notif icationid 
ent i  f ier 

{  2  9  3  2  7 
16  > 

0 

C.4.3 
.5.4. 

6 

sourcelndicato 
r 

{  2  9  3  2  7 
26  > 

0 

C.4.3 
.5.4. 

7 

stateChangeDef 
i nit  ion 

{  2  9  3  2  7 
28  > 

m 

C.A.3.5.5 

"Rec.  X.721  j 
ISO/IEC  10165-2 
:  1992": 
processingError 
Alarm 

{  2  9  3  2 
10  10  > 

ID 

C.4.3 
.5.5. 

1 

addi tional  Info 
rmation 

{  2  9  3  2  7 
6  ) 

o 

C.4.3 
.5.5. 

2 

additionalText 

{  2  9  3  2  7 
7  > 

0 

C.4.3 
.5.5. 
3 

backUpObject 

{  2  9  3  2  7 
41  > 

0 

C.4.3 
.5.5. 

4 

backedUpStatus 

{  2  9  3  2  7 
11  > 

0 

C.4.3 
.5.5. 

5 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  } 

0 

C.4.3 
.5.5. 

6 

notif icationid 
ent if ier 

{  2  9  3  2  7 
16  > 

0 

C.4.3 
.5.5. 

7 

perceivedSever 
ity 

{  2  9  3  2  7 
17  > 

m 

C.4.3 
.5.5. 

8 

probableCause 

{  2  9  3  2  7 
18  > 

m 

C.4.3 
.5.5. 

9 

proposedRepai  r 
Actions 

{  2  9  3  2  7 
19  > 

0 

C.4.3 
.5.5. 

10 

speci  f icProble 

ms 

{  2  9  3  2  7 
27  ) 

0 
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Index 

Not  i  f  i  cat  i  on 
Type  Label 

y/alue  of 
Notif icatio 
n  Type 
Identifier 

Stat 
us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

Notification 
Field  Name 
Label 

Value  of 
OID  of  Attr 
Type 

associated 
with  Field 

Stat 
us 

Suppo 
rt 

Addition 
al 

Informal 
ion 

c 

0 

n 
f 

n 

0 

n 

C.4.3 
.5.5. 
11 

stateChangeOef 
i nit  ion 

{  2  9  3  2  7 
28  > 

0 

C.4.3 
.5.5. 
12 

thresholdlnfo 

C  2  9  3  2  7 
29  > 

0 

C.4.3 
.5.5. 
13 

trendlndicatio 
n 

{  2  9  3  2  7 
30  > 

0 

C.4.3. 5. 6 

"Rec.  X.721  1 
ISO/IEC  10165-2 
:  1992": 
communicationsA 
I  arm 

C  2  9  3  2 
10  2  > 

ID 

C.4.3 
.5.6. 
1 

additionallnfo 
rmation 

{  2  9  3  2  7 
6  > 

0 

C.4.3 
.5.6. 

2 

additionalText 

{  2  9  3  2  7 
7  } 

0 

C.4.3 
.5.6. 

3 

backUpObject 

{  2  9  3  2  7 
41  > 

0 

C.4.3 
.5.6. 

4 

backedUpStatus 

{  2  9  3  2  7 
11  > 

0 

C.4.3 
.5.6. 

5 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.3 
.5.6. 

6 

notif icationid 
entif ier 

{  2  9  3  2  7 
16  > 

0 

C.4.3 
.5.6, 

7 

perceivedSever 
i  tv 

{  2  9  3  2  7 
17  } 

ID 

C.4.3 
.5.6. 
8 

probableCause 

{  2  9  3  2  7 
18  } 

m 

C.4.3 
.5.6. 

9 

proposedRepair 
Actions 

{  2  9  3  2  7 
19  > 

0 

C.4.3 
.5.6. 
10 

speci  f icProble 

fns 

{  2  9  3  2  7 
27  > 

0 

C.4.3 
.5.6. 
11 

StateChangeOef 
i nit  ion 

{  2  9  3  2  7 
28  } 

0 

C.4.3 
.5.6. 

12 

thresholdlnfo 

{  2  9  3  2  7 
29  } 

0 

C.4.3 
.5.6. 

13 

trendlndicatio 
n 

{  2  9  3  2  7 
30  ) 

0 

C.4.4    OMNIPoint  Equipment  MOCS  Proforma 


Managed  Object  class  template  label 

Value  of  Object  identifier  for  class 

"0P1  Library  Vol.  1":opEquipment 

{  1  3  14  2  2  1  4  > 
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Are  all  mandatory  features  of  the  class  supported?  Yes  No  


Table  C.4.4.1  -  Name  Binding  Support 


Index 

k 

Name  Binding  Template 
Label 

Value  of  Object 
Identifier  for 
Name  Binding 

Superior  Object 
Class  Template 
Label 

Stat 
us 

Suppo 
rt 

Status 

Suppor 
t 

Addition 
al 

Informal 
ion 

c 
r 
e 
a 
t 
e 

d 
e 
I 
e 
t 
e 

c 
r 
e 
a 
t 
e 

d 
e 
I 
e 
t 
e 

C. 4. 4. 1.1 

"Rec.  M.3100  :  1992": 
equ  i  pment - equ  i  pment 

{  0  0  13  3100  0 
6  10  > 

"Rec.  M.3100  : 
1992": equipment 

0 

m 

m 

C.4.4.1. 2 

"Rec.  M.3100  :  1992": 
equ  i  pment -ManagedE I ement 

{  0  0  13  3100  0 
6  9  > 

"Rec.  M.3100  : 
1992": 

managedElement 

0 

m 

m 

C.4.4.1. 3 

opE qui pment - 
computerSystem 

{  1  3  14  2  2  3 
10  } 

computerSystem 

0 

m 

m 

C.4.4.1. 4 

opEqu  i  pment - sys  t  em 

{  1  3  14  2  2  3 
11  > 

"Rec.  X.721  1 
ISO/IEC  10165-2  : 
1992": system 

0 

m 

m 

C. 4. 4, 1.5 

opEqu  i  pment - equ  i  pment 

{  1  3  14  2  2  3 
12  > 

"Rec.  M.3100  : 
1992":equipment 

0 

m 

m 

C.4.4.1. 6 

opEqui pment -opNet work 

<  1  3  14  2  2  3 
13  } 

opNetwork 

0 

m 

m 

I 
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Table  C.4.4.2  -  Attribute  Support 


Index 

Attribute  Template  Label 

value  OT  UDject 
Identifier  for 
Attribute 

Status 

Support 

Addi  t  iona 
I 

I nf ormflt i 
on 

s 
e 
t 
b 

y 

c 
r 
e 
a 

e 

q 
e 
t 

r 
e 
p 
I 
a 
c 
e 

a 
d 
d 

r 
e 
m 

0 
V 

e 

s 
e 
t 
t 

0 

d 
e 
f 
a 
u 
I 
t 

s 
e 
t 
b 

y 

c 
r 
e 
a 

e 

a 
e 
t 

r 
e 
p 
I 

a 
c 
e 

a 
d 
d 

r 
e 

m 

0 
V 

e 

s 
e 
t 
t 

0 

d 
e 
f 
a 
u 
I 
t 

c  L  L  2  ^ 

1992":affectedObjectList 

f  0  0  13  3100  0  7 
2  > 

X 

cO 

X 

X 

X 

X 

C.4.4.2. 2 

"Rec.  M.3100  : 

1992" : cur rentProbl emL  i  st 

{  0  0  13  3100  0  7 
17  > 

X 

cO 

X 

X 

X 

X 

C.4.4.2. 3 

"Rec.  M.3100  : 

1 992" :  I  ocat  i  onNanne 

{  0  0  13  3100  0  7 
27  > 

cO 

cO 

cO 

X 

X 

X 

C.4.4.2. 4 

"Rec.  M.3100  : 
1992": replaceable 

C  0  0  13  3100  0  7 
34  > 

X 

m 

X 

X 

X 

X 

C.4.4.2. 5 

"Rec.  M.3100  : 
1992":userLabel 

{  0  0  13  3100  0  7 
50  > 

cO 

cO 

cO 

X 

X 

X 

C.4.4.2. 6 

"Rec.  M.3100  : 
1992":vendorName 

{  0  0  13  3100  0  7 
51  > 

cO 

cO 

cO 

X 

X 

X 

C.4.4.2. 7 

"Rec.  M.3100  : 
1992": vers  ion 

{  0  0  13  3100  0  7 
52  > 

c14 

c14 

c14 

X 

X 

X 

C.4.4.2. 8 

contactList 

{13  14  2247} 

c3 

c3 

c3 

X 

X 

X 

C.4.4.2. 9 

con tact Name 

<:13  14  2248> 

CH 

ri. 
CH 

X 

C.4.4.2. 10 

customerList 

{  1  3  14  2  2  4  11 
y 

c5 

c5 

c5 

X 

X 

X 

C.4.4.2. 11 

customerName 

{  1  3  14  2  2  4  12 
} 

c6 

c6 

c6 

c6 

c6 

X 

C.4.4.2. 12 

functionList 

{  1  3  14  2  2  4  14 

■V 
J 

c7 

c7 

c7 

X 

X 

X 

C.4.4.2. 13 

functionName 

{  1  3  14  2  2  4  15 
} 

c8 

c8 

c8 

c8 

c8 

X 

C.4.4.2. 14 

locationPointer 

C  1  3  14  2  2  4  22 

\ 
J 

c9 

c9 

c9 

X 

X 

X 

C.4.4.2. 15 

manuf acturerL  i  st 

{  1  3  14  2  2  4  23 

■\ 

clO 

clO 

clO 

X 

X 

X 

C.4.4.2. 16 

manufacturerName 

{  1  3  14  2  2  4  24 
} 

c11 

c11 

c11 

c11 

c11 

X 

C.4.4.2. 17 

opNetMorkList 

{  1  3  14  2  2  4  34 
> 

c12 

c12 

c12 

X 

X 

X 

C.4.4.2. 18 

opNetuorkName 

C  1  3  14  2  2  4  35 
> 

c13 

c13 

c13 

c13 

c13 

X 

C.4.4.2. 19 

productLabel 

{  1  3  14  2  2  4  45 
} 

cO 

cO 

cO 

X 

X 

X 

C.4.4.2. 20 

serialNumber 

€  1  3  14  2  2  4  50 
> 

cO 

cO 

cO 

X 

X 

X 

C.4.4.2. 21 

serviceList 

C  1  3  14  2  2  4  51 
> 

c15 

c15 

c15 

X 

X 

X 

C.4.4.2. 22 

serviceName 

{  1  3  14  2  2  4  52 
> 

c16 

c16 

c16 

c16 

c16 

X 

C.4.4.2. 23 

sof twareList 

{  1  3  14  2  2  4  53 
> 

c17 

c17 

c17 

X 

X 

X 
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Index 

Attribute  Template  Label 

Value  of  Object 
Identifier  for 
Attribute 

Status 

Support 

Additiona 
I 

Informati 
on 

s 
e 
t 
b 

y 

C 

r 
e 

3 

t 

e 

9 
e 
t 

r 
e 

P 
I 
a 
c 
e 

a 
d 
d 

r 
e 
m 

0 
V 

e 

s 
e 
t 
t 

0 

rl 
U 

e 
f 

Q 

u 
I 
t 

s 
e 
t 
b 

y 

c 
r 
e 

Q 
t 

e 

9 
e 
t 

r 
e 

P 
I 
a 
c 
e 

a 
d 
d 

r 
e 

m 

0 
V 

e 

s 
e 
t 
t 

0 
0 

e 
f 

Q 

u 

I 

t 

C. 4, 4. 2. 24 

sof  twareNatne 

(  1  3  14  2  2  4  54 

y 

c18 

c18 

c18 

c18 

c18 

X 

C. 4. A. 2. 25 

type! ex t 

<:  1  3  14  2  2  4  59 

J 

cO 

cO 

cO 

X 

X 

X 

C. 4. 4. 2. 26 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
usageState 

{29327  39  > 

X 

c19 

X 

X 

X 

X 

C. 4. 4. 2. 27 

vendorList 

{  1  3  14  2  2  4  61 

■v 
y 

c20 

c20 

c20 

c20 

c20 

X 

C. 4. 4. 2. 28 

"Rec.  X.721   1  ISO/IEC 
10165-2  :  1992": 
opera 1 1 ona I  State 

{29327  35} 

X 

m 

X 

X 

X 

X 

C. 4. 4. 2. 29 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
3clfTii  nistrsti  VGSt3t6 

{29327  31} 

m 

m 

[D 

X 

X 

X 

C. 4. 4. 2. 30 

"Rec.  M.3100  : 
1992":alarmStatus 

{  0  0  13  3100  0  7 
6  > 

X 

c 

X 

X 

X 

X 

ttD^^r-    V  79 1    1  icn/Tcr 
Kec.  A.rcl    1  loU/lcL 

10165-2  :  1992": 

avai labi I ityStatus 

/-   p  0  7   o  7  77  -v 
V  t  y  J  t   f    jj  y 

X 

m 

X 

X 

X 

X 

C. 4. 4. 2. 32 

"Rec.  M.3100  : 
1992":equip(nentld 

{  0  0  13  3100  0  7 
20  > 

m 

m 

X 

X 

X 

X 

C. 4. 4. 2. 33 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
al lomorphs 

{  2  9  3  2  7  50  } 

Cl 

cl 

X 

X 

X 

X 

C. 4. 4. 2. 34 

"Rec.  X,721  1  ISO/IEC 
10165-2  :  1992": 
nameBinding 

{  2  9  3  2  7  63  } 

m 

m 

X 

X 

X 

X 

C. 4. 4. 2. 35 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
objectClass 

{29327  65  } 

m 

m 

X 

X 

X 

X 

C. 4. 4. 2. 36 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
packages 

{  2  9  3  2  7  66  } 

c2 

c2 

X 

X 

X 

X 
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cO 
c1 
c2 
c3 
c4 
c5 
c6 
c7 
c8 
c9 


c10=  m  i 
c11=  m  i 
c12=  m  i 
cl3=  m  i 
c14=  m  i 
c15=  m  i 
c16=  m  i 

Cl7: 

cia 

c20^ 


m  1 
m  i 


an  instance  supports  it,  else  - 

an  object  supports  allormorphism,  else  - 

any  any  registered  package  (other  than  this  package)  has  been  instantiated,  else 


else  X 


an  instance  supports 
an  instance  supports 
an  instance  supports 
an  instance  supports 
"Rec.  M.3100  :  1992" 
an  instance  supports 
an  instance  supports 
an  instance  supports 
an  instance  supports 
a  resource  can  detect 
an  instance  supports 


it 

arid 

the 

it 

and 

the 

it 

and 

the 

it 

and 

the 

it 

and 

the 

it 

and 

the 

it 

and 

the 

it 

and 

the 

it 

and 

the 

it 

and 

the 

it 

and 

the 

M.3100  :  1992":locationNamePackage  is  NOT  present. 


etuorkNamePkg  is  NOT  present,  else  x 
etworkListPkg  is  NOT  present,  else  x 
versionPackage  is  also  present  and  if  an  instance  supports  it,  else 
it  and  the  serviceNamePkg  is  NOT  present,  else  x 
it  and  the  serviceListPkg  is  NOT  present,  else  x 
it  and  the  sof twareNamePkg  is  NOT  present,  else  x 
it  and  the  sof twareListPkg  is  NOT  present,  else  x 
usage,  else  - 

it  and  the  "Rec.  M.3100  :  1992":vendorNamePackage  is  NOT  present. 


Table  C.4.4.3  -  Attribute  Group  Support 


Index 

Attribute  Group  Template  Label 

Value  of  Object 

Status 

Suppor 

Additional  Information 

Identifier  for 

t 

Attribute  Group 

9 

s 

9 

s 

e 

e 

e 

e 

t 

t 

t 

t 

t 

t 

0 

0 

d 

d 

e 

e 

f 

f 

a 

a 

u 

u 

I 

I 

t 

t 

C.4.4.3. 1 

"Rec.  X.721  1  ISO/IEC  10165-2  : 

{  2  9  3  2  8  1  } 

m 

X 

1992": state 
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Table  C.4.4.5  -  Notification  Support 


Index 

Notification 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 
us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

Notification 
Field  Name 
Label 

Value  of  Istat 
OID  of  Attrkjs 

Suppo 
rt 

Additiona 
I 

Informati 

on 

c 

0 

n 
f 

n 

0 

n 

lype 

associated 
with  Field 

C.4.4.5. 1 

"Rec.  X.721  1 
ISO/IEC  10165- 
2  :  1992": 
attributeValue 
Change 

{  2  9  3  2 
10  1  ) 

m 

C.4.4 
.5.1. 
1 

add  i  t  i  ona 1 1 nf o 
rtnation 

{  2  9  3  2  7 
6  > 

0 

C.4.4 
.5.1. 

2 

additionalText 

{  2  9  3  2  7 
7  > 

0 

C.4.4 
.5.1. 

3 

attributeldent 
if ierList 

{  2  9  3  2  7 
8  > 

0 

C.4.4 
.5.1. 

4 

at"  t  r  i  but  eVa  ( ue 
ChangeDef initi 
on 

{  2  9  3  2  7 
10  > 

fn 

C.4.4 
.5.1. 

5 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.4 
.5.1. 

6 

1  \\J  \  \    \    \  larQ  L  1  \i\  1  I  \t 

entif ier 

{  2  9  3  2  7 
16  > 

0 

C.4.4 
.5.1. 

7 

r 

{  2  9  3  2  7 
26  > 

0 

C.4.4.5. 2 

"Rec,  X.721  1 
ISO/IEC  10165- 
2  :  1992": 
objectCreation 

C  2  9  3  2 
10  6  > 

m 

r  L  L 
.5.2. 
1 

dUU  1  L  1  Ui  Id  I  1 1 1 1  l.^ 

rmation 

{  2  9  3  2  7 
6  > 

0 

C.4.4 
.5.2. 

2 

{  2  9  3  2  7 
7  } 

0 

C.4.4 
.5.2. 
3 

at'^rihiit'^l  ict' 

{  2  9  3  2  7 
9  } 

0 

C.4.4 
.5.2. 

4 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

r  L  L 
.5.2. 
5 

r\r\ Y  \  ^  1  /*af  1  r\r\  I H 
1  lu  LI  1  1  c  a  u  1  yj\  1 1  u 

entif ier 

{  2  9  3  2  7 
16  ) 

0 

C  L  L 

.5.2. 

6 

r 

{  2  9  3  2  7 
26  ) 

0 

C.4.4.5. 3 

"Rpr    X  7/>1  ! 
ISO/IEC  10165- 
2  :  1992": 
objectOeletion 

{  2  9  3  2 
10  7  > 

ITt 

C.4.4 
.5.3. 
1 

f)dd  1 1 1  ona  1 1  nf  o 
rmation 

{  2  9  3  2  7 
6  > 

0 

C.4.4 
.5.3. 

2 

addi  tionalText 

{  2  9  3  2  7 
7  > 

0 

C.4.4 
.5.3. 

3 

attributeList 

{  2  9  3  2  7 
9  > 

0 

C.4.4 
.5.3. 

4 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.4 
.5.3. 

5 

notif icationid 
entif ier 

{  2  9  3  2  7 
16  } 

0 
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Index 

Notification 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 
us 

Suppor 
t 

AQU 

Info 

oUD 

Index 

Not  i  f  i  cat  i  on 
Field  Name 
Label 

Value  of 
010  of  Attr 
Type 

associated 
with  Field 

Stat 
us 

Suppo 
rt 

Add  i  t  i  ona 
I 

Informati 
on 

c 

0 

n 
f 

n 

0 

n 

C.4.4 
.5.3. 

6 

sourcelndicato 
r 

{  2  9  3  2  7 
26  > 

0 

C.4.4.5.4 

"Rec.  X.721  j 
ISO/IEC  10165- 
2  :  1992": 
stateChange 

{  2  9  3  2 
10  14  } 

tn 

C.4.4 
.5.4. 
1 

addi  tional Info 
rmation 

{  2  9  3  2  7 
6  > 

0 

C.4.4 
.5.4. 

2 

additionalText 

{  2  9  3  2  7 
7  > 

0 

C.4.4 
.5.4. 

3 

attributeldent 
if ierList 

{  2  9  3  2  7 
8  > 

0 

C.4.4 
.5.4. 

4 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.4 
.5.4. 

5 

notif icationid 
ent  i  f  i  er 

{  2  9  3  2  7 
16  > 

0 

C.4.4 
.5.4. 

6 

sourcelndicato 
r 

{  2  9  3  2  7 
26  > 

0 

C.4.4 
.5.4. 

7 

stateChangeDef 
inition 

{  2  9  3  2  7 
28  ) 

m 

C. 4. 4. 5.5 

"Rec.  X.721  1 
ISO/IEC  10165- 
2  :  1992": 
communications 
Alarm 

{  2  9  3  2 
10  2  > 

m 

C.4.4 
.5.5. 
1 

addi  tional Info 
rmation 

{  2  9  3  2  7 
6  > 

0 

C.4.4 
.5.5. 

2 

addi  tionalText 

{  2  9  3  2  7 
7  > 

0 

C.4.4 
.5,5. 

3 

backUpObject 

{  2  9  3  2  7 
41  > 

0 

C.4.4 
.5.5. 

4 

backedUpStatus 

{  2  9  3  2  7 
11  > 

0 

C.4.4 
.5.5. 

5 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  } 

0 

C.4.4 
.5.5. 

6 

notif icationid 
entif ier 

{  2  9  3  2  7 
16  > 

0 

C.4.4 
.5.5. 

7 

perceivedSever 
ity 

{  2  9  3  2  7 
17  > 

m 

C.4.4 
.5.5. 

8 

probableCause 

{  2  9  3  2  7 
18  > 

m 

C.4.4 
.5.5. 

9 

proposedRepai  r 
Actions 

{  2  9  3  2  7 
19  > 

0 

C.4.4 
.5.5. 

10 

speci  f icProble 
ms 

{  2  9  3  2  7 
27  ) 

0 

C.4.4 
.5.5. 

1 

StateChangeDef 
inition 

{  2  9  3  2  7 
28  > 

0 
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Index 

Noti  f ication 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 
us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

Notification 
Field  Name 
Label 

Value  of 
OID  of  Attr 
Type 

1  a  LCU 

uith  Field 

Stat 
us 

Suppo 
rt 

Additions 
I 

Informati 
on 

c 

0 

n 
f 

n 

0 

n 

C.4.4 
.5.5. 
1 

thresholdlnfo 

{  2  9  3  2  7 
29  > 

0 

C.4.4 
.5.5. 

13 

trendlndicatio 
n 

{  2  9  3  2  7 
30  > 

0 

C.4.4. 5. 6 

"Rec.  X.721  1 
ISO/IEC  10165- 
2  :  1992": 
process ingErro 
rAlarm 

{  2  9  3  2 
10  10  > 

m 

C.4.4 
.5.5. 
1 

additional  Info 
rmat  i  on 

{  2  9  3  2  7 
6  > 

0 

C.4.4 
.5.5. 

2 

additionalText 

{  2  9  3  2  7 
7  > 

0 

C.4.4 
.5.5. 

3 

backUpObject 

{  2  9  3  2  7 
41  > 

0 

C.4.4 
.5.5. 

4 

backedUpStatus 

{  2  9  3  2  7 
11  > 

0 

C.4.4 
.5.5. 

5 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.4 
.5.5. 

6 

notif icationid 
entif ier 

{  2  9  3  2  7 
16  > 

0 

C.4.4 
.5.5. 

7 

perceivedSever 
ity 

{  2  9  3  2  7 
17  > 

in 

c.4.4 
.5.5. 

a 

o 

probableCause 

{  2  9  3  2  7 
18  > 

n 

c.4.4 
.5.5. 
9 

proposedRepair 
Actions 

{  2  9  3  2  7 
19  > 

0 

C.4.4 
.5.5. 

10 

specif icP rob I e 
ms 

{  2  9  3  2  7 
27  > 

0 

C.4.4 
.5.5. 
11 

stateChangeDef 
i nit  ion 

{  2  9  3  2  7 
28  > 

0 

C.4.4 
.5.5. 

12 

thresholdlnfo 

{  2  9  3  2  7 
29  > 

0 

C.4.4 
.5.5. 
13 

trendlndicatio 
n 

{  2  9  3  2  7 
30  > 

0 

C.4.4. 5. 7 

r 

"Rec.  X.721  1 
ISO/IEC  10165- 
2  :  1992": 
envi  ronmentalA 
I  arm 

{  2  9  3  2 
10  3  > 

m 

C.4.4 
.5.6. 
1 

addi  tional Info 
rmat ion 

{  2  9  3  2  7 
6  } 

0 

C.4.4 
.5.6. 

2 

additionalText 

{  2  9  3  2  7 
7  > 

0 

C.4.4 
.5.6. 
3 

backUpObject 

{  2  9  3  2  7 
41  > 

0 

C.4.4 
.5.6. 

4 

backedUpStatus 

{  2  9  3  2  7 
11  > 

o 

124 


PART  18:  Network  Management 


December  1992  (Stable) 


Index 

Notification 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 
us 

Supi 
t 

c 

0 

n 

f 

por 
n 

0 

n 

Add 
Info 

Sub- 
Index 

Notification 
Field  Name 
Label 

Value  of 
OID  of  Attr 
Type 

associated 
with  Field 

Stat 
us 

Suppo 
rt 

Additiona 
I 

Informati 
on 

C,4.4 
.5.6. 

5 

correlatedNoti 
fi cat  ions 

C  2  9  3  2  7 
12  > 

0 

C.4.4 
.5.6. 

6 

notif icationid 
entif ier 

C  2  9  3  2  7 
16  > 

0 

C.4.4 
.5.6. 

7 

perceivedSever 
ity 

{  2  9  3  2  7 

17  > 

ID 

C.4.4 
.5.6. 
8 

probableCause 

{  2  9  3  2  7 
18  > 

tn 

C.4.4 
.5.6. 

9 

proposedRepair 
Actions 

{  2  9  3  2  7 
19  > 

0 

C.4.4 
.5.6. 

10 

specif icProble 
ms 

{  2  9  3  2  7 
27  } 

0 

C.4.4 
.5.6. 

1  1 
1  1 

stateChangeDef 
ini  tion 

{  2  9  3  2  7 

28  > 

0 

C.4.4 
.5.6. 

1 P 

thresholdinf 0 

{  2  9  3  2  7 
29  > 

0 

c.4.4 
.5.6. 

13 

trendlndicatio 
n 

{  2  9  3  2  7 
30  ) 

0 

C.4.4.5.8 

"Rec.  X.721  1 
ISO/IEC  10165- 
2  :  1992": 
equipmentAlarm 

{  2  9  3  2 
10  4  > 

m 

C.4.4 
.5.7. 

addi  tional Info 
rmation 

{  2  9  3  2  7 
6  } 

0 

C.4.4 
.5.7. 

addi  tional Text 

{  2  9  3  2  7 
7  > 

0 

C.4.4 
.5.7. 

J 

backUpObject 

{  2  9  3  2  7 
41  ) 

0 

C.4.4 
.5.7. 

/. 
H 

backedUpStatus 

{  2  9  3  2  7 
11  > 

0 

C.4.4 
.5.7. 

5 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.4 
.5.7. 

z 
O 

notif icationid 
ent  i  f  i  er 

{  2  9  3  2  7 
16  > 

0 

c.4.4 
.5.7. 

7 

perceivedSever 
ity 

{  2  9  3  2  7 
17  } 

m 

C.4.4 
.5.7. 

8 

probableCause 

{  2  9  3  2  7 
18  } 

m 

C.4.4 
.5.7. 

9 

proposedRepai  r 
Actions 

{  2  9  3  2  7 
19  > 

0 

C.4.4 
.5.7. 

10 

specif icProble 
ms 

{  2  9  3  2  7 
27  > 

0 
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Index 

Notification 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 
us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

Notification 
Field  Name 
Label 

Value  of 
DID  of  Attr 
Type 

associated 
with  Field 

Stat 
us 

Suppo 
rt 

Additiona 
I 

Informati 
on 

c 

0 

n 
f 

n 

0 

n 

C.4.4 
.5.7. 

11 

stateChangeDef 
i nit  ion 

C  2  9  3  2  7 
28  > 

0 

C.4.4 
.5.7. 

12 

thresholdlnfo 

C  2  9  3  2  7 
29  > 

0 

C.4.4 
.5.7. 
13 

trendlndicatio 
n 

C  2  9  3  2  7 
30  > 

0 

C.4.5    OMNIPoint  Network  MOCS  Proforma 


Managed  Object  class  template  label 

Value  of  Object  identifier  for  class 

"0P1  Library  Vol.  1":opNetwork 

{  1  3  14  2  2  1  5  > 

Are  all  mandatory  features  of  the  class  supported?  Yes   No 


Table  C.4.5.1  -  Name  Binding  Support 


Index 

Name  Binding  Template 
Label 

Value  of  Object 
Identifier  for 
Name  Binding 

Superior  Object 
Class  Template 
Label 

Stat 
us 

Suppo 
rt 

Status 

Suppor 
t 

Additiona 
I 

Informati 
on 

c 
r 
e 
a 
t 
e 

d 
e 
I 
e 
t 
e 

c 
r 
e 
a 
t 
e 

d 
e 
I 
e 
t 
e 

C.4.5. 1.1 

"Rec.  M.3100  :  1992": 
network-network 

{  0  0  13  3100  0 
6  17  > 

"Rec.  M.3100  : 

1992": 

network 

0 

X 

X 

C.4.5. 1.2 

network-opNetwork- 1 

{  1  3  14  2  2  3 
14  ) 

"Rec.  M.3100  : 

1992": 

network 

0 

m 

m 

C.4.5. 1.3 

network-opNetwork-2 

{  1  3  14  2  2  3 
15  > 

"Rec.  M.3100  : 

1992": 

network 

0 

m 

m 

C.4.5, 1.4 

opNetwork-root 

{  1  3  14  2  2  3 
16  > 

"Rec.  X.600  I 
I  SO/ 1  EC  9834-1  : 
1992": root 

0 

m 

m 
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Table  C.4.5.2  -  Attribute  Support 


I  ndGX 

Attribute  Tentotdte  Label 

Value  of  Object 

Status 

Support 

Add 1 t 1 ona 

Identifier  for 

I 

Attribute 

s 

9 

r 

a 

r 

s 

s 

9 

r 

a 

r 

s 

Informati 

- 

e 

e 

e 

d 

e 

e 

e 

e 

e 

d 

e 

e 

on 

t 

t 

P 

d 

ID 

t 

t 

t 

p 

d 

Tl 

t 

b 

I 

0 

t 

b 

I 

0 

t 

y 

a 

V 

0 

y 

a 

V 

0 

c 

c 

e 

d 

c 

c 

e 

d 

r 

e 

e 

r 

e 

e 

e 

t 

e 

T 

a 

a 

a 

a 

t 

u 

t 

u 

e 

I 

e 

1 

C.4.5.2. 1 

"Rec.  M.3100  : 

{  0  0  13  3100  0  7 

m 

m 

X 

X 

X 

X 

1992":networkId 

3  ) 

C.4.5.2. 2 

"Rec.  M.3100  : 

{  0  0  13  3100  0  7 

cO 

cO 

cO 

X 

X 

X 

1992""userLabel 

50  > 

C.4.5.2. 3 

network! i  tie 

C  1  3  14  2  2  4  31 

m 

m 

X 

X 

X 

X 

C.4.5.2. 4 

"Rec.  X.721  1  I  SO/ 1  EC 

{29327  50} 

Cl 

cl 

X 

X 

X 

X 

10165-2  :  1992": 

al lomorphs 

C.4.5.2. 5 

"Rec.  X.721  1  ISO/IEC 

<:29327  63  } 

m 

m 

X 

X 

X 

X 

10165-2  :  1992": 

nameBinding 

C.4.5.2. 6 

"Rec.  X.721  j  ISO/IEC 

C29327  65  } 

m 

m 

X 

X 

X 

X 

10165-2  :  1992": 

objectClass 

C.4.5.2. 7 

"Rec.  X.721   1  ISO/IEC 

{29327  66  > 

c2 

c2 

X 

X 

X 

X 

10165-2  :  1992": 

packages 

cO  =  m  if  an  instance  supports  it,  else  - 

cl  =  m  if  an  object  supports  al lormorphism,  else  - 

c2  =  m  if  any  any  registered  package  (other  than  this  package)  has  been  instantiated,  else 
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Table  C.4.5.5  -  Notification  Support 


Index 

Notification 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 
us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

Not  i  f  i  cat  i  on 
Field  Name 
Label 

Value  of 
OID  of  Attr 
Type 

associated 
with  Field 

Stat 
us 

Suppo 
rt 

Add  i  t  i  ona 
I 

Informati 
on 

c 

0 

n 
f 

n 

0 

n 

C. 4. 5. 5.1 

"Rec.  X.721  1 
ISO/IEC  10165- 
2  :  1992": 
attributeValue 
Change 

{  2  9  3  2 
10  1  > 

m 

C.4.5 
.5.1. 

1 

addi  tional Info 
rmation 

C  2  9  3  2  7 
6  > 

0 

C.4.5 
.5.1. 

2 

addi  tional Text 

C  2  9  3  2  7 
7  > 

0 

C.4.5 
.5.1. 

3 

attributeldent 
if ierList 

C  2  9  3  2  7 
8  > 

0 

C.4.5 
.5.1. 

4 

attributeValue 
ChangeDef initi 
on 

{  2  9  3  2  7 
10  > 

m 

C.4.5 
.5.1. 

5 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.5 
.5.1. 

6 

notif icationid 
entif ier 

{  2  9  3  2  7 
16  > 

0 

C.4.5 
.5.1. 

7 

sourcelndicato 
r 

{  2  9  3  2  7 
26  > 

0 

C.4.5.5. 2 

"Rec.  X.721  1 
ISO/IEC  10165- 
2  :  1992": 
objectCreation 

<  2  9  3  2 
10  6  } 

m 

C.4.5 
.5.2. 

1 

addi  tional Info 
rmation 

{  2  9  3  2  7 
6  ) 

0 

C.4.5 
.5.2. 

2 

addi  tional Text 

{  2  9  3  2  7 
7  > 

0 

C.4.5 
.5.2. 

3 

attributeList 

{  2  9  3  2  7 
9  > 

0 

C.4.5 
.5.2. 

4 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.5 
.5.2. 

5 

notif icationid 
entif ier 

{  2  9  3  2  7 
16  } 

0 

C.4.5 
.5.2. 

6 

sourcelndicato 
r 

{  2  9  3  2  7 
26  > 

0 

C.4.5.5. 3 

"Rec.  X,721  1 
ISO/IEC  10165- 
2  :  1992": 
objectDeletion 

C  2  9  3  2 
10  7  } 

m 

C.4.5 
.5.3. 

1 

addi tional Info 
rmation 

{  2  9  3  2  7 
6  ) 

0 

C.4.5 
.5.3. 

2 

addi  tionalText 

{  2  9  3  2  7 
7  } 

0 

C.4.5 
.5.3. 

3 

attributeList 

{  2  9  3  2  7 
9  > 

0 

C.4.5 
.5.3. 

4 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  } 

0 

C.4.5 
.5.3. 

5 

notif icationid 
entif ier 

{  2  9  3  2  7 
16  > 

0 
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Index 

Noti  f ication 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 
us 

Suppo r 
t 

Add 
Info 

Sub- 
Index 

Notification 
Field  Name 
Label 

Value  of 
OID  of  Attr 
Type 

associated 
with  Field 

Stat 
us 

Suppo 
rt 

Additiona 
I 

Informati 
on 

c 

0 

n 
f 

n 

0 

n 

.5.3. 

6 

sourcelndicato 
r 

{  2  9  3  2  7 
26  > 

0 

C.4,6    Processing  Entity  MOCS  Proforma 


Managed  Object  class  template  label 

Value  of  Object  identifier  for  class 

"OPI  Library  Vol.  1":processingEntity 

{  1  3  14  2  2  1  6  } 

Are  all  mandatory  features  of  the  class  supported?  Yes   No 


Table  C.4.6.1  -  Name  Binding  Support 


Index 

Name  Binding  Template 
Label 

Value  of  Object 
Identifier  for 
Name  Binding 

Superior  Object 
Class  Template 
Label 

Stat 
us 

Suppo 
rt 

Status 

Supper 
t 

Addition 
al 

Informat 
ion 

c 
r 
e 
a 
t 
e 

d 
e 
I 
e 
t 
e 

c 
r 
e 
a 
t 
e 

d 
e 
I 
e 
t 
e 

C. 4. 6. 1.1 

"Rec.  M.3100  :  1992": 
equ  i  pment - equ  i  pmen t 

{  0  0  13  3100  0 
6  10  } 

"Rec.  M.3100  : 
1992": equipment 

0 

m 

m 

C.4.6.1. 2 

"Rec.  M.3100  :  1992": 
equ  i  pment - ManagedE I ement 

{  0  0  13  3100  0 
6  9  } 

"Rec.  M.3100  : 
1992": 

managedElement 

0 

m 

m 

C.4.6.1. 3 

opEqui pment - 
computerSystem 

{  1  3  14  2  2  3 
10  > 

computerSystem 

0 

m 

m 

C.4.6.1. 4 

opEqu  i  pment - sys  t  em 

{  1  3  14  2  2  3 
11  > 

"Rec.  X.721  1 
ISO/IEC  10165-2  : 
1992":system 

0 

m 

m 

C.4.6.1. 5 

opEqui  pment - equ  i  pment 

{  1  3  14  2  2  3 
12  > 

"Rec.  M.3100  : 
1992":equipment 

0 

m 

m 

C.4.6.1. 6 

opE qui pment -opNetwork 

<:  1  3  14  2  2  3 
13  > 

opNetwork 

0 

m 

m 
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Table  C.4.6.2  -  Attribute  Support 


Index 

Attribute  Template  Label 

Value  of  Object 
Identifier  for 
Attribute 

Status 

Support 

Additiona 
I 

Informati 
on 

s 
e 
t 
b 

y 

c 
r 
e 
a 
t 
e 

9 
e 
t 

r 
e 

P 
I 

a 
c 
e 

a 
d 
d 

r 
e 
m 

Q 

v 
e 

s 
e 
t 

0 

d 
e 
f 
a 
u 
I 

s 
e 
t 

y 

c 
r 
e 
a 
t 
e 

g 
e 
t 

r 
e 

P 
I 

a 
c 
e 

a 
d 
d 

r 
e 
m 

0 
V 

e 

s 
e 
t 
( 

0 

d 
e 
f 
a 
u 
I 

C.4.6.2. 1 

"Rec.  M.3100  : 

1992":af fectedObjectList 

C  0  0  13  3100  0  7 
2  > 

X 

cO 

X 

X 

X 

X 

C.4.6.2. 2 

"Rec.  M.3100  : 

1992" :currentProblemL  i  st 

C  0  0  13  3100  0  7 
17  > 

X 

cO 

X 

X 

X 

X 

C.4.6.2. 3 

"Rec.  M.3100  : 
1992": locationName 

C  0  0  13  3100  0  7 
27  > 

cO 

cO 

cO 

X 

X 

X 

C.4.6.2. 4 

"Rec.  M.3100  : 
1992": replaceable 

{  0  0  13  3100  0  7 
34  > 

X 

m 

X 

X 

X 

X 

C.4.6.2. 5 

"Rec.  M.3100  : 
1992":userLabel 

{  0  0  13  3100  0  7 
50  ) 

cO 

cO 

cO 

X 

X 

X 

C.4.6.2. 6 

"Rec.  M.3100  : 
1 992" :  vendorNatne 

{  0  0  13  3100  0  7 
51  > 

cO 

cO 

cO 

X 

X 

X 

C.4.6.2. 7 

"Rec.  M.3100  : 
1992": vers ion 

{  0  0  13  3100  0  7 
52  ) 

c14 

c14 

c14 

X 

X 

X 

C.4.6.2. 8 

contactList 

{13  14  2247} 

c3 

c3 

c3 

X 

X 

X 

C.4.6.2. 9 

contactName 

{13  14  2248} 

c4 

c4 

c4 

c4 

c4 

X 

C.4.6.2. 10 

customerList 

{  1  3  14  2  2  4  11 

c5 

c5 

c5 

X 

X 

X 

C.4.6.2. 11 

customerName 

{  1  3  14  2  2  4  12 

c6 

c6 

c6 

c6 

c6 

X 

C.4.6.2. 12 

functionList 

{  1  3  14  2  2  4  14 

c7 

c7 

c7 

X 

X 

X 

C.4.6.2. 13 

functionName 

{  1  3  14  2  2  4  15 

c8 

c8 

c8 

c8 

c8 

X 

C.4.6.2. 14 

locationPointer 

{  1  3  14  2  2  4  22 

c9 

c9 

c9 

X 

X 

X 

C.4.6.2. 15 

manufacturerList 

{  1  3  14  2  2  4  23 

clO 

clO 

clO 

X 

X 

X 

C.4.6.2. 16 

manufacturerName 

{  1  3  14  2  2  4  24 

c11 

c11 

c11 

c11 

c11 

X 

C.4.6.2. 17 

opNetworkList 

{  1  3  14  2  2  4  34 

c12 

c12 

c12 

X 

X 

X 

C.4.6.2. 18 

opNet work Name 

{  1  3  14  2  2  4  35 

c13 

c13 

c13 

c13 

c13 

X 

C.4.6.2. 19 

productLabel 

{  1  3  14  2  2  4  45 

cO 

cO 

cO 

X 

X 

X 

C.4.6.2. 20 

serialNumber 

{  1  3  14  2  2  4  50 

cO 

cO 

cO 

X 

X 

X 

C.4.6.2. 21 

serviceList 

{  1  3  14  2  2  4  51 

c15 

c15 

c15 

X 

X 

X 

C.4.6.2. 22 

serviceName 

{  1  3  14  2  2  4  52 

c16 

c16 

c16 

c16 

c16 

X 

C.4.6.2. 23 

sof twareList 

{  1  3  14  2  2  4  53 

c17 

c17 

c17 

X 

X 

X 
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Value  of  Object 
Identifier  for 
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Status 

Support 

Additiona 

1 

I 

Informat j 
on 

s 

t 
b 
y 
c 
r 
e 
a 
t 
e 

g 
t 

r 

Q 

P 
I 

a 
c 
e 

a 
d 
d 

r 

Q 

m 

0 
V 

e 

s 

Q 

t 
t 

0 

d 
e 
f 
a 
u 
I 
t 

s 

Q 
t 

b 
y 
c 
r 
e 
a 
t 
e 

g 

t 

r 

Q 

P 
I 

a 
c 
e 

a 
d 

r 

Q 

fn 

0 
V 

e 

s 

Q 
t 
t 

0 

d 
e 
f 
a 
u 
I 
t 

C. 4. 6. 2. 24 

sof twareName 

C  1  3  14  2  2  4  54 
> 

c18 

c18 

c18 

c18 

c18 

X 

C. 4. 6. 2. 25 

typeText 

<:  1  3  14  2  2  4  59 
> 

cO 

cO 

cO 

X 

X 

X 

C. 4. 6. 2. 26 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
usageState 

{29327  39} 

X 

c19 

X 

X 

X 

X 

C. 4. 6. 2. 27 

vendorList 

{  1  3  14  2  2  4  61 
> 

c20 

c20 

c20 

c20 

c20 

X 

C. 4. 6. 2. 28 

"Rec.  X.721  j  ISO/IEC 
10165-2  :  1992": 
operational  State 

{29327  35} 

X 

m 

X 

X 

X 

X 

C. 4. 6. 2. 29 

"Rec.  X.721  ]  ISO/IEC 
10165-2  :  1992": 
administrat i veState 

{29327  31  } 

m 

m 

m 

X 

X 

X 

C. 4. 6. 2. 30 

"Rec.  M.3100  : 
1992":alarmStatus 

{  0  0  13  3100  0  7 
6  > 

X 

c 

X 

X 

X 

X 

C. 4. 6. 2.31 

"Rec.  X.721   I  ISO/IEC 
10165-2  :  1992": 
avai labi I i  tyStatus 

{  2  9  3  2  7  33  ) 

X 

m 

X 

X 

X 

X 

C. 4. 6. 2. 32 

"Rec.  M.3100  : 
1992":equipmentld 

{  0  0  13  3100  0  7 
20  > 

m 

m 

X 

X 

X 

X 

C. 4. 6. 2. 33 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
allomorphs 

{29327  50} 

Cl 

cl 

X 

X 

X 

X 

C. 4. 6. 2. 34 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
nameBinding 

{29327  63  } 

m 

m 

X 

X 

X 

X 

C. 4. 6. 2. 35 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
objectClass 

{29327  65  > 

m 

m 

X 

X 

X 

X 

C. 4. 6. 2. 36 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
packages 

{29327  66} 

c2 

c2 

X 

X 

X 

X 

C. 4. 6. 2. 37 

address i ngS i  ze 

{13  14  2242} 

X 

c21 

X 

X 

X 

X 

C. 4. 6. 2. 38 

endianess 

{  1  3  14  2  2  4  13 
> 

X 

c21 

X 

X 

X 

X 

C. 4. 6. 2. 39 

cpuUti lization 

{  1  3  14  2  2  4  10 
> 

X 

cO 

X 

X 

X 

X 

C. 4. 6. 2. 40 

memorySi  ze 

{  1  3  14  2  2  4  28 
> 

X 

c21 

X 

X 

X 

X 

C. 4. 6. 2. 41 

memoryUti lization 

{  1  3  14  2  2  4  29 
> 

X 

cO 

X 

X 

X 

X 

C. 4. 6. 2. 42 

upT  i  me 

{  1  3  14  2  2  4  60 
> 

X 

cO 

X 

X 

X 

X 

C. 4. 6. 2. 43 

cpuType 

{13  14  2249) 

X 

m 

X 

X 

X 

X 

C. 4. 6. 2. 44 

oslnfo 

{  1  3  14  2  2  4  36 
} 

X 

m 

X 

X 

X 

X 
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else  X 


cO  = 

m 

if 

c1  = 

m 

if 

c2  = 

m 

if 

c3  = 

m 

if 

c4  = 

m 

if 

c5  = 

m 

if 

c6  = 

m 

if 

c7  = 

m 

if 

c8  = 

tn 

if 

c9  = 

m 

if 

c10= 

m 

if 

c11  = 

m 

if 

c12= 

m 

if 

c13= 

m 

if 

cU= 

m 

if 

c15= 

m 

if 

c16= 

m 

if 

c17= 

m 

if 

c18= 

m 

if 

c19= 

m 

if 

c20= 

m 

if 

c21  = 

m 

if 

an  instance  supports  it,  else  - 

an  object  supports  al lormorphism,  else  - 

any  any  registered  package  (other  than  this  package)  has  been  instantiated,  else  - 

an  instance  supports  it  and  the  contactNamePkg  is  NOT  present,  else  x 

an  instance  supports  it  and  the  contactListPkg  is  NOT  present,  else  x 

an  instance  supports  it  and  the  customerNamePkg  is  NOT  present,  else  x 

an  instance  supports  it  and  the  customerListPkg  is  NOT  present,  else  x 

an  instance  supports  it  and  the  functionNamePkg  is  NOT  present,  else  x 

an  instance  supports  it  and  the  functionListPkg  is  NOT  present,  else  x 

an  instance  supports  it  and  the  "Rec.  M.3100  :  1992": locationNamePackage  is  NOT  present. 


an  instance  supports 
an  instance  supports 
an  instance  supports 
an  instance  supports 
"Rec.  M.3100  :  1992" 
an  instance  supports 
an  instance  supports 
an  instance  supports 
an  instance  supports 
a  resource  can  detect 
an  instance  supports 


it  and  the  manufacturerNamePkg  is  NOT  present,  else  x 
it  and  the  manufacturerListPkg  is  NOT  present,  else  x 
it  and  the  opNetworkNamePkg  is  NOT  present,  else  x 
it  and  the  opNetworkListPkg  is  NOT  present,  else  x 
versionPackage  is  also  present  and  if  an  instance  supports  it,  else 
it  and  the  serviceNamePkg  is  NOT  present,  else  x 
it  and  the  serviceListPkg  is  NOT  present,  else  x 
it  and  the  sof twareNamePkg  is  NOT  present,  else  x 
it  and  the  sof twareListPkg  is  NOT  present,  else  x 
usage,  else  - 

it  and  the  "Rec.  M.3100  :  1992": vendor NannePackage  is  NOT  present. 


tn  if  relevant  to  the  underlying  resource,  else 


Table  C.4.6.3  -  Attribute  Group  Support 


Index 

Attribute  Group  Template  Label 

Value  of  Object 

Status 

Suppor 

Additional  Information 

Identifier  for 

t 

Attribute  Group 

9 

s 

9 

s 

e 

e 

e 

e 

t 

t 

t 

t 

t 

t 

0 

0 

d 

d 

e 

e 

f 

f 

a 

a 

u 

u 

I 

I 

t 

t 

C.4.6.3. 1 

"Rec.  X.721  1  ISO/IEC  10165-2  : 

{  2  9  3  2  8  1  } 

m 

X 

1992":state 
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Index 

Noti  f ication 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 
us 

Suppor 
t 

Add 
Info 

Index 

NOLI TICall on 

Field  Name 
Label 

Value  UT 

OID  of  Attr 
Type 

associated 
with  Field 

C  t- 

o  tat 
us 

Suppo 
rt 

Addi t  i  ona 
I 

Informal i 
on 

c 

0 

n 
f 

n 

0 

n 

C.4.6.5. 1 

"Rec.  X.721  [ 
ISO/IEC  10165- 
2  :  1992": 
attributeValue 
Change 

{  2  9  3  2 
10  1  > 

m 

C.4.6 
.5.1. 

1 

additionallnfo 
rmation 

{  2  9  3  2  7 
6  > 

0 

C.4.6 
.5.1. 

2 

additionalText 

{  2  9  3  2  7 
7  > 

0 

C.4.6 
.5.1. 

3 

attributeldent 
if ierList 

{  2  9  3  2  7 
8  > 

0 

C.4.6 
.5.1. 

4 

attributeValue 
ChangeDef initi 
on 

{  2  9  3  2  7 
10  > 

m 

C.4.6 
.5.1. 

5 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  } 

0 

C.4.6 
.5.1. 

6 

notif icationid 
entif ier 

{  2  9  3  2  7 
16  } 

0 

C.4.6 
.5.1. 

7 

sourcelndicato 
r 

{  2  9  3  2  7 
26  } 

0 

C.4.6.5. 2 

"Rec.  X.721  1 
ISO/IEC  10165- 
2  :  1992": 
objectCreation 

{  2  9  3  2 
10  6  > 

m 

C.4.6 
.5.2. 

1 

addi  tional Info 
rmation 

{  2  9  3  2  7 
6  > 

0 

C.4.6 
.5.2. 

2 

addi  tional Text 

{  2  9  3  2  7 
7  > 

0 

C.4.6 
.5.2. 

3 

attributeList 

{  2  9  3  2  7 
9  } 

0 

C.4.6 
.5.2. 

4 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.6 
.5.2. 

5 

notif icationid 
ent  i  f  i  er 

{  2  9  3  2  7 
16  > 

0 

C.4.6 
.5.2. 

6 

sourcelndicato 
r 

{  2  9  3  2  7 
26  > 

0 

C.4.6.5. 3 

"Rec.  X.721  I 
ISO/IEC  10165- 
2  :  1992": 
objectDeletion 

{  2  9  3  2 
10  7  > 

m 

C.4.6 
.5.3. 

1 

additional  Info 
rmation 

{  2  9  3  2  7 
6  } 

0 

C.4.6 
.5.3. 

2 

additionalText 

{  2  9  3  2  7 
7  } 

0 

C.4.6 
.5.3. 

3 

attributeList 

{  2  9  3  2  7 
9  } 

0 

C.4,6 
.5.3. 

4 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.6 
.5.3. 

5 

notif icationid 
ent i  f ier 

{  2  9  3  2  7 
16  > 

0 
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Index 


Notification 
Type  Label 


Value  of 
Notif icatio 
n  Type 
Identifier 


Stat 
us 


Suppor 

t 

c 

n 

0 

0 

n 

n 

f 

Add 
Info 


Sub- 
Index  Field 


Notification 

Name 
Label 


Value  of 
OID  of 
Type 

associated 
with  Field 


Stat 
Attn  us 


Suppo  Addi 
rt 


C.4.6.5.4 


C.4 

.5.3 
6 


6  sourcelndicato 

r 


C  2  9  3  2  7|o 
26  > 


"Rec.  X.721  I 
ISO/IEC  10165- 
2  :  1992": 
stateChange 


{  2  9  3  2  |m 
10  14  > 


C.4 
.5.4 

1 


6  addi  tionallnfo 
rmation 


<:  2  9  3  2  7|o 
|6  > 


C.4. 6  addi tionalText 
.5.4 
2 


C  2  9  3  2  7|o 
7  > 


C.4 
5.4 

3 


6attributeldent 
if ierList 


C  2  9  3  2  7|o 
8  > 


C.4 
.5.4 

4 


6  correlatedNoti 
fi cat ions 


{  2  9  3  2  7 
12  > 


C.4. 
5.4 

5 


6notif icationid 
entif ier 


{  2  9  3  2  7 
16  > 


C.4 
.5.4 

6 


6  sourcelndicato 
r 


{  2  9  3  2  7 
26  > 


C.4 

5.4 
7 


6|stateChange0ef 
i nit  ion 


{  2  9  3  2  7 
28  > 


C.4. 6. 5. 5 


"Rec.  X.721  I 
ISO/IEC  10165- 
2  :  1992": 
conmuni cat  ions 
Alarm 


{  2  9  3  2 
10  2  } 


C.4 

.5.5 

1 


6 addi tionallnfo 
rmat  i  on 


{  2  9  3  2  7|o 
6  > 


C.4. 6  addi  tionalText 
.5.5 
2 


{  2  9  3  2  7|o 
7  } 


C.4.6backUpObject 
.5.5. 
3 


{  2  9  3  2  7lo 
41  > 


C .  4 . 6  bac  kedUpS  t  a  t  us 
5.5 

4 


{  2  9  3  2  7 
11  > 


C.4 
.5.5 

5 


6 correlatedNoti 
fi cat  ions 


{  2  9  3  2  7 
12  > 


C.4 

.5.5 

6 


6  noti  f icationid 
ent  i  f  i  er 


{  2  9  3  2  7|o 
16  > 


C.4 
5.5 

7 


6perceivedSever 
ity 


{  2  9  3  2  7h 
17  > 


C .  4 . 6  probabl eCause 
.5.5. 
8 


{  2  9  3  2  7h 
18  > 


C.4. 
5.5 

9 


6  proposedRepai  r 
Actions 


{  2  9  3  2  7|o 
19  > 


C.4 
.5.5 
10 


6specif icProble 
ms 


{  2  9  3  2  7|o 
27  > 


C.4. 

.5.5 
11 


6stateChangeDef 
inition 


{  2  9  3  2  7|o 
28  } 
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Notification 
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n  Type 
Identifier 

Stat 
us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

Noti  f ication 
Field  Name 
Label 

Value  of 
OID  of  Attn 
Type 

associated 
with  Field 

Stat 
us 

Suppo 
rt 

Additiona 
I 

Informati 
on 

c 

0 

n 
f 

n 

0 

n 

C.4.6 
.5.5. 

thresholdlnfo 

{  2  9  3  2  7 
29  } 

0 

c.4.6 
.5.5. 

17 

trendlndicatio 
n 

{  2  9  3  2  7 
30  > 

0 

C.4.6. 5. 6 

"Rec.  X.721  1 
ISO/IEC  10165- 
2  :  1992": 
processingErro 
rAlarm 

{  2  9  3  2 
10  10  > 

ID 

c.4.6 
.5.5. 
1 

additionallnfo 
rmation 

{  2  9  3  2  7 
6  > 

0 

C.4.6 
.5.5. 

2 

additionalText 

{  2  9  3  2  7 
7  > 

0 

C.4.6 
.5.5. 

3 

backUpObject 

{  2  9  3  2  7 
41  > 

0 

C.4.6 
.5.5. 

4 

backedUpStatus 

{  2  9  3  2  7 
11  > 

0 

C.4.6 
.5.5. 
5 

correlatedNoti 
fi cat ions 

{  2  9  3  2  7 
12  > 

0 

C.4.6 
.5.5. 

6 

notif icationid 
entif ier 

{  2  9  3  2  7 
16  > 

0 

C.4.6 
.5.5. 

7 

pence ivedSever 
ity 

{  2  9  3  2  7 
17  } 

m 

C.4.6 
.5.5. 

8 

probableCause 

{  2  9  3  2  7 
18  > 

m 

C.4.6 
.5.5. 
9 

proposedRepair 
Actions 

{  2  9  3  2  7 
19  > 

0 

C.4.6 
.5.5. 

10 

specif icP rob I e 
ms 

{  2  9  3  2  7 
27  > 

0 

C.4.6 
.5.5. 
11 

stateChangeDef 
i nit  ion 

{  2  9  3  2  7 
28  } 

0 

C.4.6 
.5.5. 

12 

thresholdlnfo 

{  2  9  3  2  7 
29  > 

0 

C.4.6 
.5.5. 
13 

trendlndicatio 
n 

{  2  9  3  2  7 
30  } 

0 

C.4.6. 5. 7 

"Rec.  X.721  1 
ISO/IEC  10165- 
2  :  1992": 
environmentalA 
tarm 

{  2  9  3  2 
10  3  ) 

m 

C.4.6 
.5.6. 

1 

additionallnfo 
rmation 

{  2  9  3  2  7 
6  } 

0 

C.4.6 
.5.6. 

2 

additionalText 

{  2  9  3  2  7 
7  } 

0 

C.4.6 
.5.6. 

3 

backUpObject 

{  2  9  3  2  7 
41  > 

0 

C.4.6 
.5.6. 

4 

backedUpStatus 

{  2  9  3  2  7 
11  } 

0 
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Suppor  Kdd~ 
t  Info 


Index 


Notification    Value  of 
Type  Label  Notificatio 
n  Type 
Identifier 


Sub- 
Index 


Notification 
Field  Name 
Label 


Value  of 
OID  of  Attr 
Type 

associated 
with  Field 


Stat 

LIS 


Suppo 
rt 


Additiona 
I 

I nf ormat  i 
on 


C.4.6 
.5.7. 
11 


C.4.6 

.5.7 
12 


C.4.6 

.5.7 
13 


stateChangeDef 
i nit  ion 


{  2  9  3  2  7 
28  > 


thresholdinf 0 


<  2  9  3  2  7|o 
29  > 


trendlndicatio 

n 


<  2  9  3  2  7|o 

BO  } 


C.4.7    Transport  Connection  MOCS  Proforma 


Managed  Object  class  template  label 

Value  of  Object  identifier  for  class 

"0P1  Library  Vol.  1":transportConnection 

C  1  3  14  2  2  1  7  } 

Are  all  mandatory  features  of  the  class  supported? 

Table  C.4.7.1 


Yes 

mg  Su 


No 


Index 

Name  Binding  Template 

Value  of  Object 

Superior  Object 

Stat 

Suppo 

Status 

Suppor 

Addition 

Label 

Identifier  for 

Class  Template  Label 

us 

rt 

t 

al 

Name  Binding 

c 

d 

c 

d 

I  nf ormat 

r 

e 

r 

e 

ion 

e 

I 

e 

I 

a 

e 

a 

e 

t 

t 

t 

t 

e 

e 

e 

C.4.7. 1.1 

t  ranspor tConnec  t  i  on- 

{  1  3  14  2  2  3 

coT ranspor tProtoco I L 

0 

X 

m 

coTransportProtocol Layer 

17  } 

ayerEntity 

Entity 
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Table  C.4.7.2  -  Attribute  Support 


Index 

Attribute  Template  Label 

Value  of  Object 
Identifier  for 

Status 

Support 

Additions 
I 

Attribute 

s 
e 
t 
b 

y 

c 
r 
e 
a 
t 
e 

9 
e 
t 

r 
e 

P 
I 
a 
c 
e 

a 
d 
d 

r 
e 
m 

0 
V 

e 

s 
e 
t 
t 

0 

d 
e 
f 
a 
u 
I 
t 

s 
e 
t 
b 

y 

c 
r 
e 
a 
t 
e 

g 

e 
t 

r 
e 

P 
I 
a 
c 
e 

a 
d 
d 

r 
e 

fn 

0 
V 

e 

s 
e 
t 
t 

0 

d 
e 
f 
a 
u 
I 
t 

Infornnati 
on 

C.4.7.2. 1 

maxRet ransmi  ss  i  ons 

{  1  3  14  2  2  4  27 
> 

X 

cO 

X 

X 

X 

X 

C.4.7.2. 2 

ret ransmi ss i onT i me 

{  1  3  14  2  2  4  48 
> 

X 

cO 

X 

X 

X 

X 

C.4.7.2. 3 

retransmissicnTimerIni t ialV 
alue 

{  1  3  14  2  2  4  49 
} 

X 

cO 

X 

X 

X 

X 

C.4.7.2. 4 

"Rec.  X.721   1  I  SO/ 1  EC 
10165-2  :  1992": 
pdusRetransmi ttedErrorCount 
er 

{  2  9  3  2  7  87  } 

X 

cO 

X 

X 

X 

X 

C.4.7.2. 5 

"Rec.  X.721   1  I  SO/ 1  EC 
10165-2  :  1992": 
octetsRetransmi  ttedErrorCou 
nter 

(29327  79  } 

X 

cO 

X 

X 

X 

X 

C.4.7.2. 6 

"Rec.  X.721   j  I  SO/ 1  EC 

10165-2  :  1992": 

puudKc  L 1  anbiii  1 1  tcruc  rrui  i  n  i  co 

hold 

{29327102} 

X 

cO 

cO 

X 

X 

X 

C.4.7.2. 7 

"Rec.  x.721   j  ISO/IEC 
10165-2  :  1992": 
outgoingProtocolErrorCounte 
r 

(29327  85  } 

cO 

C.4.7.2. 8 

checksumPDUsD  i  scardedCounte 
r 

{  1  3  14  2  2  4  3 
} 

X 

cO 

X 

X 

X 

X 

C.4.7.2. 9 

localTransportConnect lonEnd 
point 

{  1  3  14  2  2  4  21 
} 

X 

m 

X 

X 

X 

X 

C.4.7.2. 10 

remote! ranspor tConnect  i  onEn 
dpoint 

{  1  3  14  2  2  4  47 
} 

X 

m 

X 

X 

X 

X 

C.4.7.2. 11 

transportConnectionRef erenc 
e 

{  1  3  14  2  2  4  57 
} 

X 

m 

X 

X 

X 

X 

r  A  7  5  15 

I oca  I Net work Address 

V    1   J    Ih  c  c  H  10 
} 

X 

m 

X 

X 

X 

X 

C.4.7.2. 13 

remoteNetworkAddress 

{  1  3  14  2  2  4  46 
} 

X 

m 

X 

X 

X 

X 

C.4.7.2. 14 

inactivityTimeout 

{  1  3  14  2  2  4  17 
} 

X 

m 

X 

X 

X 

X 

C.4.7.2. 15 

inactivi  tyTime 

{  1  3  14  2  2  4  16 
} 

X 

m 

X 

X 

X 

X 

C.4.7.2. 16 

maxPDUS  i  ze 

{  1  3  14  2  2  4  26 
} 

X 

m 

X 

X 

X 

X 

C.4.7.2. 17 

"Rec.  x.721  1  ISO/IEC 
10165-2  :  1992": 
pdusSent Counter 

(29327  88} 

X 

m 

X 

X 

X 

X 

C.4.7.2. 18 

"Rec.  X.721  j  ISO/IEC 
10165-2  :  1992": 
pdusRecei vedCounter 

(29327  86} 

X 

m 

X 

X 

X 

X 
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Index 

Attribute  Template  Label 

Value  of  Object 
Identifier  for 

Status 

Support 

Add  i  t { ond 

I 

Attribute 

s 
e 
t 
b 

y 

c 
r 

e 
a 
t 
e 

9 
e 
t 

r 

I 
a 

a 
d 
d 

r 

e 
m 

0 
V 

e 

s 
e 
t 
t 

t 

f 

a 

t 

s 
e 
t 

b 

\ 

e 
a 

g 

e 
t 

r 
e 
p 

I 
a 
c 
e 

a 
d 
d 

r 

e 
n 

0 
V 

e 

s 
e 
t 
t 

0 

d 
e 
f 
a 
u 
I 
t 

Informati 
on 

C.4.7.2.19 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
octetsSentCounter 

C29327  80  } 

X 

m 

X 

X 

X 

C. 4. 7.2. 20 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
octetsReceivedCounter 

{  2  9  3  2  7  78  > 

X 

m 

X 

X 

___ 
X 



C.A.7.2.21 

"Rec.  X-721  1  ISO/IEC 
10165-2  :  1992": 
incomingProtocolErrorCounte 
r 

<29327  77  > 

X 

m 

X 

X 

X 

C. 4. 7.2. 22 

transport Connect  i  onl d 

{  1  3  14  2  2  4  56 
> 

X 

m 

X 

X 

X 

C.4.7.2.23 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
al lomorphs 

{  2  9  3  2  7  50  } 

X 

Cl 

X 

X 

X 

X 

H 

C.4.7.2.24 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
nameBinding 

€29327  63  } 

X 

m 

X 

X 

X 

X 

- 

C. 4. 7. 2. 25 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
objectClass 

{29327  65} 

X 

m 

X 

X 

X 

X 

C. 4. 7.2. 26 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
packages 

C2932766} 

X 

c2 

H 

X 

X 

cO  =  m  if  an  instance  supports  it,  else  - 

cl  =  m  if  an  object  supports  al lormorphism,  else  - 

c2  =  m  if  any  any  registered  package  (other  than  this  package)  has  been  instantiated,  else  - 
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Table  C.4.7.5  -  Notification  Support 


Index 

Notification 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 
us 

Suppor 
t 

Add 
Info 

Ci  ih- 

dUU 

Index 

NOW  1 T 1 caK 1  on 
Field  Name 
Label 

Wall  1 A  f\f 

010  of  Attr 
Type 

associated 
with  Field 

dial 
us 

Suppo 
rt 

Addi  t  iona 
I 

Informati 
on 

c 

0 

n 
f 

n 

0 

n 

C. 4. 7.5.1 

j 

"Rec.  X.721  j 
ISO/IEC  10165- 
2  :  1992": 
attributeValue 
Change 

{  2  9  3  2 
10  1  > 

m 

C.4.7 
.5.1. 
1 

additionallnfo 
rmation 

{  2  9  3  2  7 
6  > 

0 

C.4.7 
.5.1. 

2 

additional  Text 

{  2  9  3  2  7 
7  > 

0 

C.4.7 
.5.1. 

3 

attributeldent 
if ierList 

{  2  9  3  2  7 
8  > 

0 

C.4.7 
.5.1. 

4 

attributeValue 
ChangeOef ini  ti 
on 

{  2  9  3  2  7 
10  > 

n 

C.4.7 
.5.1. 

5 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  } 

0 

C.4.7 
.5.1. 

6 

notifications 
ent  i  f  i  er 

{  2  9  3  2  7 
16  > 

0 

C.4.7 
.5.1. 

7 

sourcelndicato 
r 

{  2  9  3  2  7 
26  > 

0 

C.4.7.5. 2 

"Rec.  X.721  1 
ISO/IEC  10165- 
2  :  1992": 
objectCreation 

C  2  9  3  2 
10  6  } 

m 

C.4.7 
.5.2. 

1 

additionallnfo 
rmation 

{  2  9  3  2  7 
6  > 

0 

C.4.7 
.5.2. 

2 

additional  Text 

{  2  9  3  2  7 
7  ) 

0 

C.4.7 
.5.2. 
3 

attributeList 

{  2  9  3  2  7 
9  > 

0 

C.4.7 
.5.2. 

4 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.7 
.5.2. 

5 

notif icationid 
entif ier 

{  2  9  3  2  7 
16  > 

0 

C.4.7 
.5.2. 

6 

sourcelndicato 
r 

{  2  9  3  2  7 
26  > 

0 

C.4.7.5. 3 

"Rec.  X.721  1 
ISO/IEC  10165- 
2  :  1992": 
objectOeletion 

{  2  9  3  2 
10  7  > 

m 

C.4.7 
.5.3. 

1 

additionallnfo 
rmation 

{  2  9  3  2  7 
6  > 

0 

C.4,7 
.5.3. 

2 

additionalText 

{  2  9  3  2  7 
7  ) 

0 

C.4.7 
.5.3. 
3 

attributeList 

{  2  9  3  2  7 
9  > 

0 

C.4.7 
.5.3. 

4 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.7 
.5.3. 

5 

notif icationid 
ent  i  f  i  er 

{  2  9  3  2  7 
16  > 

0 
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Index 

Notification 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 
us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

Notification 
Field  Name 
Label 

Value  of 
OID  of  Attr 
Type 

associated 
with  Field 

Stat 
us 

Suppo 
rt 

Additiona 
I 

I  nf ormat  i 
on 

c 

0 

n 
f 

n 

0 

n 

C.4.7 
.5.3. 

6 

sourcelndicato 
r 

{  2  9  3  2  7 
26  > 

0 

C. 4. 7.5. 4 

"Rec.  X.721  j 
ISO/IEC  10165- 
2  :  1992": 
conmuni cat  ions 
Alarm 

{  2  9  3  2 
10  2  ) 

cO 

C.4.7 
.5.4. 

1 

additional  Info 
rmation 

{  2  9  3  2  7 
6  > 

0 

C.4.7 
.5.4. 

2 

additional  Text 

{  2  9  3  2  7 
7  > 

0 

C.4.7 
.5.4. 

backUpObject 

{  2  9  3  2  7 
41  > 

0 

C.4.7 
.5.4. 

A 

backedUpStatus 

{  2  9  3  2  7 
11  > 

0 

C.4.7 
.5.4. 

C 
J 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  } 

0 

C.4.7 
.5.4. 
6 

notif icationid 
ent  i  f  i  er 

{  2  9  3  2  7 
16  > 

0 

C.4.7 
.5.4. 

7 

percei vedSever 
ity 

{  2  9  3  2  7 
17  > 

nfi 

C.4.7 
.5.4. 

8 

probableCause 

{  2  9  3  2  7 
18  ) 

m 

C.4.7 
.5.4. 

9 

proposedRepai  r 
Actions 

{  2  9  3  2  7 
19  } 

0 

C.4.7 
.5.4. 

10 

specif icP rob I e 
ms 

{  2  9  3  2  7 
27  } 

0 

C.4.7 
.5.4. 

11 

stateChangeDef 
i nit  ion 

{  2  9  3  2  7 
28  } 

0 

C.4.7 
.5.4. 

12 

thresholdlnfo 

{  2  9  3  2  7 
29  > 

0 

C.4.7 
.5.4. 

13 

t rend I nd icatio 
n 

{  2  9  3  2  7 
30  > 

0 

cO  =  m  if  instance  supports  it,  else  - 

C.4.8    Transport  Connection  IVMO  MOCS  Proforma 


Managed  Object  class  template  label 

Value  of  Object  identifier  for  class 

"0P1  Library  Vol.  2":transportConnectionIVM0 

{  1  3  14  2  1  1  1  > 

Are  all  mandatory  features  of  the  class  supported?  Yes   No 
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Table  C.4.8.1  -  Name  Binding  Support 


Index 

Name  Binding  Template 
Label 

Value  of  Object 
Identifier  for 
Name  Binding 

Superior  Object 
Class  Template  Label 

Stat 
us 

Suppo 
rt 

Status 

Suppor 
t 

Addition 

Bl 

Informat 
ion 

c 
r 
e 
a 
t 
e 

d 
e 
I 
e 
t 
e 

c 
r 
e 
a 
t 
e 

d 
e 
I 
e 
t 
e 

C. 4. 8. 1.1 

transportConnectionlVMO- 
coT  ranspor tP  rotoco I  Layer 
Entity 

<  1  3  14  2  1  3  1 
> 

"DPI  Library  Vol. 
1": 

coTransportProtocolL 
ayerEntity 

o 

X 

X 
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Table  C.4.8.2  -  Attribute  Support 


Index 

Attribute  Template  Label 

Value  of  Object 
Identifier  for 

Status 

Support 

Additiona 
I 

Attribute 

s 
e 
t 
b 

w 
7 

c 
r 
e 
a 
t 
e 

3 
e 
t 

r 
e 

P 
I 

c 
e 

a 
a 
d 

r 
e 
m 

0 

y 

e 

s 
e 
t 
t 

Q 

d 

e 
f 
a 
u 
I 
t 

s 
e 
t 
b 
\i 

7 

c 
r 
e 
a 
t 
e 

9 
e 
t 

r 
e 

P 
I 

c 
e 

a 
d 
d 

r 
e 

0 

e 

s 
e 
t 
t 

0 

d 
e 
f 
a 
u 
I 
t 

I nf ormat  i 
on 

C.4.8.2. 1 

"0P1  Library  Vol. 
1": inactivityTimeout 

{  1  3  14  2  2  4  17 
> 

m 

m 

[D 

X 

X 

X 

C.4.8.2. 2 

"0P1  Library  Vol. 
1":maxPDUSize 

{  1  3  14  2  2  4  26 

> 

m 

m 

[D 

X 

X 

X 

C.4.8.2. 3 

t  ranspor tConnec  t  i  on I VMO I d 

{  1  3  14  2  1  4  1 
) 

X 

m 

X 

X 

X 

X 

C.4.8.2. 4 

"Rec.  X.721  1  I  SO/ 1  EC 
10165-2  :  1992": 
al lomorphs 

<:29327  50  > 

X 

Cl 

X 

X 

X 

X 

C.4.8.2. 5 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
nameBinding 

€29327  63  } 

X 

m 

X 

X 

X 

X 

C.4.8.2. 6 

"Rec.  X.721  1  ISO/lEC 
10165-2  :  1992": 
objectClass 

{29327  65  } 

X 

m 

X 

X 

X 

X 

C.4.8.2. 7 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
packages 

<:29327  66  > 

X 

c2 

X 

X 

X 

X 

cl  =  m  if  an  object  supports  al lormorphism,  else  - 

c2  =  m  if  any  any  registered  package  (other  than  this  package)  has  been  instantiated,  else  - 


143 


PART  18:  Network  Management 


December  1992  (Stable) 


Table  C.4.8.5  -  Notification  Support 


Index 

Notification 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 
us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

Notification 
Field  Name 
Label 

Value  of 
OID  of 
Attr  Type 
associated 
with  Field 

Stat 
us 

SUDDO 

rt 

Additiona 
I 

Informati 
on 

c 

0 

n 

f 

n 

0 

n 

C.4.8.5. 1 

"Rec.  X.721  1 
ISO/IEC  10165-2 
:  1992": 
attributeValueC 
hange 

C  2  9  3  2 
10  1  > 

m 

C.4.8 
.5.1. 
1 

additional  Info 
rmation 

{  2  9  3  2 
7  6  > 

0 

C.4.8 
.5.1. 

2 

additionalText 

{  2  9  3  2 
7  7  > 

0 

C.4.8 
.5.1. 
3 

attributeldent 
if ierList 

{  2  9  3  2 
7  8  > 

0 

C.4.8 
.5.1. 

4 

attributeValue 
ChangeDef initi 
on 

{  2  9  3  2 
7  10  > 

m 

C.4.8 
.5.1. 

5 

correlatedNoti 
fi cat  ions 

{  2  9  3  2 
7  12  > 

0 

C.4.8 
.5.1. 

6 

notif icationid 
entif ier 

{  2  9  3  2 
7  16  > 

0 

C.4.8 
.5.1. 

7 

sourcelndicato 
r 

{  2  9  3  2 
7  26  } 

0 

C.4.8.5. 2 

"Rec.  X.721  1 
ISO/IEC  10165-2 
:  1992": 
objectCreation 

{  2  9  3  2 
10  6  > 

m 

C.4.8 
.5.2. 

1 

addi tionallnfo 
rmation 

{  2  9  3  2 
7  6  > 

0 

C.4.8 
.5.2. 

2 

addi  tionalText 

{  2  9  3  2 
7  7  > 

0 

C.4.8 
.5.2. 

3 

attributeList 

{  2  9  3  2 
7  9  > 

0 

C.4.8 
.5.2. 

4 

correlatedNoti 
fi cat  ions 

{  2  9  3  2 
7  12  > 

0 

C.4.8 
.5.2. 

5 

notif icationid 
ent  i  f  i  er 

{  2  9  3  2 
7  16  > 

0 

C.4.8 
.5.2. 
6 

sourcelndicato 
r 

{  2  9  3  2 
7  26  > 

0 

C.4.8.5. 3 

"Rec.  X,721  1 
ISO/IEC  10165-2 
:  1992": 
objectDeletion 

{  2  9  3  2 
10  7  > 

m 

C.4.8 
.5.3. 
1 

additional  Info 
rmation 

{  2  9  3  2 
7  6  > 

0 

C.4.8 
.5.3. 

2 

additionalText 

{  2  9  3  2 
7  7  > 

0 

C.4.8 
.5.3. 

3 

attributeList 

{  2  9  3  2 
7  9  > 

0 

C.4.8 
.5.3. 

4 

correlatedNoti 
fi cat  ions 

{  2  9  3  2 
7  12  > 

0 

C.4.8 
.5.3. 

5 

notif icationid 
entif ier 

{  2  9  3  2 
7  16  > 

0 
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Notification 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 
us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

Noti  f ication 
Field  Name 
Label 

Value  of 
010  of 
Attr  Type 
associated 
with  Field 

Stat 
us 

Suppo 
rt 

Additiona 
I 

Informati 
on 

c 

0 

n 
f 

n 

0 

n 

C.4.8 
.5.3. 

6 

sourcelndicato 
r 

{  2  9  3  2 
7  26  > 

0 

C.4.9    Transport  Connection  Retransmission  IVMO  MOCS  Proforma 


Managed  Object  class  teniplate  label 

Value  of  Object  identifier  for  class 

"0P1  Library  Vol. 

2" : t  ranspor tConnect  i  onRet  ransmi  ss  i  onl VMO 

{  1  3  14  2  1  1  3  > 

Are  all  mandatory  features  of  the  class  supported?  Yes   No 


Table  C.4.9. 1  -  Name  Binding  Support 


Index 

Name  Binding  Template  Label 

Value  of  Object 
Identifier  for 
Name  Binding 

Superior  Object 
Class  Template 
Label 

Stat 
us 

Suppo 
rt 

Status 

Suppor 
t 

Addition 
al 

Informat 
ion 

c 
r 
e 
a 
t 
e 

d 
e 
I 
e 
t 
e 

c 
r 
e 
a 
t 
e 

d 
e 
I 
e 
t 
e 

C.4.9. 1.1 

t  ranspor [Connect  i  onl VMO- 

coTransportProtocolLayerEnt 

ity 

{  1  3  14  2  1  3  1 
> 

"0P1  Library  Vol. 
1": 

coTransportProtocc 
ILayerEntity 

0 

X 

X 

C. 4. 9.1. 2 

t  ranspor tConnect  i  onRet  ransm 
issionlVMO- 

coT ranspor tProtocolLayerEnt 
ity 

{  1  3  14  2  1  3  2 
> 

"0P1  Library  Vol . 
1": 

coTransportProtocc 
ILayerEntity 

0 

X 

X 
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Table  C.4.9.2  -  Attribute  Support 


Index 

:  ...  .  ■ 

Attribute  Template  Label 

Value  of  Object 
Identifier  for 

Status 

Support 

Additional 
Information 

s 

t 
b 

y 

c 
r 
e 
a 
t 
e 

g 

G 

t 

r 

P 
I 
a 
c 
e 

a 
d 
d 

r 
m 

0 
V 

e 

s 

t 
t 

0 

d 
e 
f 

a 
u 
I 
t 

s 

t 

b 

y 

c 
r 
e 
a 
t 
e 

g 
t 

r 

Q 

P 
I 

a 
c 
e 

a 
d 

r 

in 

0 

e 

s 

t 
t 

0 

d 
e 
f 
a 
u 
I 
t 

c.4.9.2. 1 

"OPl  Library  Vol. 

1 " : maxRet  r ansmi  ss  i  ons 

<  1  3  14  2  2  4  27 
) 

m 

m 

on 

X 

X 

X 

C.4.9.2. 2 

"OPl  Library  Vol,  1": 

ret  ransmi  ss  i  onT  i  mer I ni  t  i  a I 

Value 

C  1  3  14  2  2  4  49 
> 

ID 

m 

in 

X 

X 

X 

C.4.9.2. 3 

"OPl  Library  Vol. 
1": inactivityTimeout 

<  1  3  14  2  2  4  17 

> 

m 

m 

in 

X 

X 

X 

C.4.9.2. 4 

"OPl  Library  Vol. 
1":maxP0USize 

{  1  3  14  2  2  4  26 
> 

ID 

m 

m 

X 

X 

X 

C.4.9.2. 5 

transportConnectionlVMOId 

{  1  3  14  2  1  4  1 
> 

x 

m 

X 

X 

X 

X 

C.4.9.2. 6 

"Rec.  X.721  I  ISO/IEC 
10165-2  :  1992": 
allomorphs 

{29327  50  > 

X 

Cl 

X 

X 

X 

X 

C.4.9.2. 7 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
names inding 

{29327  63  > 

X 

m 

X 

X 

X 

X 

C.4.9.2. 8 

"Rec.  X.721  j  ISO/IEC 
10165-2  :  1992": 
objectClass 

{29327  65  > 

X 

m 

X 

X 

X 

X 

C.4.9.2. 9 

"Rec.  X.721  j  ISO/IEC 
10165-2  :  1992": 
packages 

{2932766} 

X 

c2 

X 

X 

X 

X 

cl  =  m  if  an  object  supports  al lormorphism,  else  - 

c2  =  m  if  any  any  registered  package  (other  than  this  package)  has  been  instantiated,  else  - 
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Table  C.4.9.5  -  Notification  Support 


Index 

Noti  f ication 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 
us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

Notification 
Field  Name 
Label 

Value  of 
OID  of  Attr 
Type 

associated 
with  Field 

Stat 

us 

Suppo 
rt 

Addi ti ona 
I 

Informati 
on 

c 

0 

n 
f 

n 

0 

n 

C. 4. 9. 5.1 

"Rec.  X.721  1 
ISO/IEC  10165- 
2  :  1992": 
attributeValue 
Change 

{  2  9  3  2 
10  1  > 

ID 

r  L  0 
.5.1. 
1 

o/Mrt  1^1  /\r\^  1  I 

rmation 

/•  p  0  7  ?  7 
\  c.  y  J  c  t 

6  > 

0 

r  L  0 
.5.1. 

2 

dUU  1  t  1  Oria  I  1  t 

/•  p  o  ■!   p  7 

V  £  y  o  c  / 
7  > 

0 

r  L  Q 
.5.1. 

3 

if ierList 

C  ">  Q  \  '>  7 

\     C     7    J    C  1 

8  > 

0 

r  L  Q 
.5.1. 

A 

o        r*  I  rM  iiA 
at  CI  IDULcValUc 

ChangeDef ini ti 
on 

r  7  0  'K  7  7 

10  > 

fn 

r  L  Q 
u  .  *♦  .  y 

.5.1. 

5 

^    p       1  a  ^  oWW  rt ^ 1 
1  c I a  I cunu  L 1 

fi cat  ions 

/"  P  0  7  ?  7 
\  c  y  D  c  1 

12  > 

0 

r  /  o 
L  .H.y 

.5.1. 

6 

not  1 f  i  cat  1 onid 
enti  f ier 

r   0  O  7   0  7 

V  t  y  J  c  f 
16  > 

0 

r  A  0 
.5.1. 

7 

source I ndi  cato 
r 

/■  5  0  7  5  7 
V  c  y  J  c  f 

26  > 

0 

C.4.9.5. 2 

"Rec.  X.721  1 
ISO/IEC  10165- 
2  :  1992": 
objectCreation 

{  2  9  3  2 
10  6  > 

m 

.5.2. 

1 

add  i  t  i  ona  1 1  nf  o 
rmation 

r  5  0  7  9  7 
V  t  y  J  c  f 

6  > 

0 

L .  H .  y 
.5.2. 

2 

addi t  i  ona I Text 

i-  o  0  7  P  7 

V  t  y  J  / 
7  > 

0 

L  -H  .y 
.5.2. 
3 

attributeList 

r  0  O  "Z  O  7 
{.  c  y  J  d  1 

9  } 

0 

r  ^  0 
.5.2. 
A 

fi cat  ions 

v  b  y  J  c  f 
12  > 

0 

C.'i.V 
.5.2. 

5 

not  i  f  icat  ionid 
entif ier 

y  o  o  1  O  7 
i  c  y  5  c  f 

16  > 

0 

C.4.9 
.5.2. 

6 

sourcelndicato 
r 

26  > 

0 

r  A  o  7 

Kec .  A . f  c 1  1 
ISO/IEC  10165- 
2  :  1992": 
objectDeletion 

/•  o  o  7  o 
K  c  y  J  c 

10  7  > 

m 

u  -H  ,y 
.5.3. 
1 

add  i  t  i  ona 1 1 nf o 
rmation 

f    O   Q   T    0  7 

\  c  y  J  c  ( 
6  ) 

0 

C.4.9 
.5.3. 

2 

additional  Text 

{  2  9  3  2  7 
7  > 

0 

C.4.9 
.5.3. 

3 

attributeList 

{  2  9  3  2  7 
9  > 

0 

C.4.9 
.5.3. 

4 

correlatedNoti 
f icat ions 

{  2  9  3  2  7 
12  > 

0 

C.4.9 
.5.3. 

5 

notif icationid 
entif ier 

{  2  9  3  2  7 
16  > 

0 
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Suppo 
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Informati 
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6 

sourcelndicato 
r 

(29327 
26  > 

0 
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Foreword 


This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Remote  Database  Access  Special 
Interest  Group  (RDA  SIG)  of  the  Open  Systems  Environment  Implementors'  Workshop  (OWN).  See  Procedure 
Manual  for  Workshop  Charter. 

Text  In  this  part  has  been  approved  by  the  Plenary  of  the  Workshop.  This  part  replaces  the  previously 
existing  part  on  this  subject. 

Future  changes  and  additions  to  this  version  of  these  implementation  Agreements  will  be  published  as 
change  pages.  Deleted  and  replaced  text  will  be  shown  as  strikeout.  New  and  replacement  text  will  be 
shown  as  shaded. 

The  text  in  this  part  contains  a  set  of  Remote  Database  Access  (RDA)  Implementation  Agreements  intended 
to  serve  in  lieu  of  an  International  Standardized  Profile  (ISP)  for  RDA.  It  is  the  aim  of  the  OIW  RDA  SIG  to 
pursue  alignment  of  this  part  with  a  future  RDA  ISP.  When  the  ISP  is  complete,  this  part  will  be  revised  to 
refer  to  the  ISP.  and  to  only  highlight  additional  practices  and  North  American  regional  requirements. 
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Part  19  -  Remote  Database  Access 


0  Introduction 

This  part  defines  Implementation  Agreements  isased  on  ISO  Remote  Database  Access,  as  defined  in  ISO/ 
lEC  9579.  That  specification  has  two  parts.  Part  1  defines  the  RDA  Generic  Model,  Service,  and  Protocol; 
part  2  defines  the  RDA  SQL  Specialization. 

1  Scope 

This  implementation  agreement  addresses  Interactbn  between  an  application  program  and  a  remote 
database  server.  The  database  server  is  an  open  system  that  provides  database  storage  facilities  and 
supplies  database  processing  services  to  clients  at  other  open  systems. 

The  RDA  service-provider  supplies  the  protocol  for  RDA  client  interaction  with  an  RDA  server.  The  RDA 
client  initiates  an  RDA  dialogue  and  requests  RDA  operations  to  be  performed  by  the  RDA  server  on  behalf 
of  an  application  program.  The  RDA  server,  located  within  the  RDA  database  server,  provides  database 
services  to  RDA  clients. 

More  specifically,  this  document  describes  implementation  agreements  in  the  following  areas: 

a)  limitations  on  values  of  parameters  of  the  RDA  protocol; 

b)  other  restrictions  on  operations  of  an  RDA  client  or  server; 

c)  profiles. 

These  agreements  presently  include  only  the  RDA  SQL  Specialization  Basic  Application  Context. 

2  Status 

The  following  clauses  were  moved  to  the  Stable  Implementation  Agreements  in  December  1992  : 


0 

Introduction 

1 

Scope 

2 

Status 

3 

Normative  references 

4 

Definitions  and  abbreviations 

5 

Structure  of  RDA  standards 

6 

SQL  specialization 
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Annex  A  (normative).  RDA  SIG  object  identifiers 

3    Normative  r@ferenc@s 


The  following  documents  contain  provisions  wliich,  through  reference  in  this  text,  constitute  provisions  of 
these  implementation  Agreements.  At  the  time  of  publication,  the  editions  indicated  were  valid.  All 
documents  are  subject  to  revision,  and  parties  to  agreements  based  on  these  Implementation  Agreements 
are  warned  against  automatically  applying  any  more  recent  editions  of  the  documents  listed  below  since  the 
nature  of  references  made  by  the  Implementation  Agreements  to  such  documents  is  that  they  may  be 
specific  to  a  particular  edition.  Members  of  lEC  and  ISO  maintain  registers  of  currently  valid  International 
StBTKlards.  and  CCITT  maintains  published  editions  of  its  current  recommendations. 


[1]      ISO/IEC  9579-1  Information  Processing  Systems  •  Open  Systems  Interconnection 
Database  Access  -  Part  1:  Generic  Model,  Service,  and  Protocol. 


Remote 


[2]      ISO/IEC  9579-2  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Remote 
Database  Access  -  Part  2:  SQL  Specialization. 

[3]       ISO/IEC  TR1 0000-1 :  1990(E)  Information  Technology  -  Framework  and  Taxonomy  of  International 
Standardized  Profiles  -  Part  1:  Framework. 


[4]       ISO/IEC  TR10000-2:  1990(E)  Information  Technology  -  Framework  and  Taxonomy  of  International 
Standardized  Profiles  -  Pan  2:  Taxonomy. 

[5]       ISO/IEC  8859-1 :1987  Information  Processing  -  8-bit  single-byte  coded  graphic  characters  sets  - 
Part  1:  Latin  alphabet  No.  1. 

4  Definitions  and  abbreviations 

Definitions  and  abbreviations  are  given  in  the  standards  listed  In  clause  3. 

5  Structure  of  RDA  standards 

The  complete  specification  of  an  RDA  Service  Is  only  obtained  by  the  combination  of  two  standards: 

a)  the  RDA  Generic  Model.  Sen^ice,  and  Protocol  (ISO/IEC  9579-1),  which  specifies  general 
capabilities  of  any  RDA  service;  and 

b)  an  RDA  Specialization,  which  applies  to  a  particular  type  of  database  language  and  augments 
the  RDA  Generic  standard. 

Since  RDA  Specializations  "complete"  an  RDA  specification,  these  Implementation  Agreements  are  based 
on  RDA  Specializations  rather  than  on  the  RDA  Generic  standard. 

At  present  there  is  only  one  RDA  Specialization,  the  RDA  SQL  Specialization  (ISO/IEC  9579-2). 
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6    SQL  specialization 


6.1      Service  parameter  limits/agreements 

This  subclause  states  the  limits  on  the  values  of  RDA  parameters  for  the  RDA  Basic  Application  Context. 

NOTE  -  Limits  for  the  RDA  TP  Application  Context  will  be  defined  at  a  later  time. 

A  tabular  format  is  used  to  describe  the  usage  of  each  RDA  parameter  and  its  limit.  Limits  vary  among 
implementations.  This  subclause  defines  the  range  of  parameter  values  that  developers  may  safely  assume 
all  OlW-compliant  systems  support. 

Each  parameter  tatsle  indicates  the  following: 

a)  the  name  of  the  parameter; 

b)  whether  it  is  sent  in  the  request  or  response  service  primitive  under  these  Implementation 
Agreements; 

c)  whether  it  is  received  in  the  indication  or  confirm  service  primitive  under  these  Implementation 
Agreements; 

d)  the  limitations  on  the  parameter. 

The  Parameter  column  gives  the  name  of  the  parameter  or  type,  as  defined  in  either  the  service  parameter 
tables  or  the  ASN.1  for  the  protocol  data  units  of  ISO/IEC  9579-1  and  9579-2. 

NOTE  -  Parameter  names  begin  with  a  lowercase  letter,  and  type  names  begin  with  an  uppercase  letter. 

The  req  (ind)  column  states  whether  the  parameter  is  present  in  the  request  (indication)  service  primitive 
event. 

The  rsp  (cnf)  column  states  whether  the  parameter  is  present  in  the  response  (confirm)  service  primitive 
event. 

The  Limitation  column  gives  the  limits  on  the  parameter  value  in  addition  to  any  limits  imposed  by  the 
RDA  standard.  The  maximum  value  indicated  for  the  limit  imposed  by  these  Implementation  Agreements 
is  a  min-max  limit.  This  means  that  an  OlW-compliant  implementation  must  support  minimally  at  least  the 
min-max  value.  An  implementation  can  support  values  beyond  the  min-max  value  but  it  can  not  expect  other 
implementations  to  do  the  same.  Hence,  an  implementation  should  stay  within  the  min-max  limit  when  it 
is  Interoperating  with  another  implementation. 

If  a  parameter  value  is  outside  the  range  specified  In  the  Limitation  column  for  that  parameter,  then  the 
behavior  is  outside  the  scope  of  these  Implementation  Agreements. 

Each  RDA  parameter  is  listed  on  a  separate  line.  Some  parameters  are  structures,  composed  of 
subparameters.  The  structure  is  shown  by  the  bullet  (•)  symbols  in  the  parameter  column.  A  parameter 
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name  preceded  by  bullets  is  a  subparameter  of  the  nearest  entry  above  it  that  has  one  fewer  bullet.  In  the 
example  below,  parameterA  and  parameters  are  subparameters  of  the  structure  parameter  parametefX,  and 
parameterC  Is  a  subparameter  of  parameters  : 


par3m6t8rX 

•parameterA 
« parameters 
»♦  parameterC 


The  presence  of  subparameters  Is  always  dependent  on  the  presence  of  the  parameter  that  they  appear 
under  (for  example,  an  optional  parameter  may  have  subparameters;  if  the  parameter  Is  not  supplied,  then 

no  subparameters  may  be  suppiied). 

Under  each  req,  ind,  rsp.  or  cnf  column,  a  code  is  used  to  specify  the  type  of  usage  of  each  RDA  parameter. 
For  the  sake  of  explanation,  let  x  represent  the  entry  under  columns  req,  rsp,  ind,  and  cnf. 

If  X  is  M,  the  parameter  is  mandatory. 

If  X  is  U,  the  parameter  is  a  user  option  and  may  or  may  not  be  provided,  depending  upon  the  requirements 
of  the  user. 

If  X  is  C,  the  parameter  is  conditional  and  subject  to  rules  stated  in  the  parameter  description  in  ISO/IEC 
9579-1  and  9579-2. 

If  X  is  S,  the  parameter  is  a  mandatory  selection  from  a  collection  of  two  or  more  possible  parameters.  The 
parameters  that  make  up  this  collection  are  indicated  In  the  parameter  table  as  follows: 

a)  each  parameter  in  the  collection  is  specified  with  the  code  "S"; 

b)  the  name  of  each  parameter  in  the  collection  has  the  same  number  of  bullets  preceding  it  in  the 
parameter  column  in  the  table;  and 

c)  either 

1)  each  parameter  has  no  bullets  preceding  it  in  the  table;  or 

2)  each  parameter  is  part  of  the  same  structure  parameter. 


If  X  is  1,  the  parameter  is  out  of  the  scope  of  this  profile.  The  parameter  is  optional  in  the  base  standard  but 
Is  not  used  by  this  profile,  or  the  parameter  is  not  used  by  the  RDA  SQL  specialization.  The  parameter  may 
be  present.  If  present,  it  is  ignored  or  processed  according  to  local  procedures;  it  does  not  cause  an  error. 

A  blank  code  indicates  the  parameter  is  never  present. 

If  X  includes  (=),  the  parameter  is  semantically  equivalent  to  the  parameter  in  the  service  primitive  to  its  left 
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6.1.1.1.1  R-lnitialize  request 


Table  1  -  Parameters  for  R-lnitialize  request 


farafneier 

req 

Inu 

LImnailOn 

operationID 

M 

M(= 
) 

An  INTEGER  with  value  greater  than 

0. 

dialoguelD 

M 

M(= 
) 

See  subparameter(s)  t)elow. 

•dialoguelDQient- 
invocation 

M 

See  subparameter(s)  below. 

••aP-tWe 

M 

M(= 
) 

No  additional  limitation. 

••aE-qualifier 

M 

M(= 
) 

No  additional  limitation. 

••aP-invocationID 

M 

M(= 

) 

No  additional  limitation. 

••aE-invovationID 

M 

M(= 
) 

No  additional  limitation. 

•dialoguelDSuffix 

M 

M(= 
) 

An  OCTET  STRING  from  1  through  64 
octets  long. 

identityOfUser 

M 

M(= 
) 

A  VisibleString  from  1  through  64 
characters  long. 

userAuthenticationData 

1 

l(=) 

The  client  may  provide  an  lASString 
from  1  through  255  characters  long, 

an  r^r*TPT  QTRIM<^  frnm  1  thrniinh 

all  v^v./ 1  c  1  oiniiNO  iiuiii  1  iiiiuuyii 
255  octets  long,  or  a  BIT  STRING 
from  1  through  2040  bits  long. 

contrdServiceData- 
Requested 

(default  value:  FALSE) 

M 

M(= 
) 

No  additional  limitation. 

functionalUnitsRequested 

M 

M(= 
) 

No  additional  limitation. 

sQUnrtializeArgument 

U 

C(= 

) 

See  subparameter(s)  t>elow. 

 ,  ,  .  

•sQLConformanceLevel- 
Default 

U 

C(= 
) 

An  OBJECT  IDENTIFIER  from  2 
through  1 6  elements. 

•userData 



1 

l(  =  ) 

An  OCTET  STRING  from  1  through 
255  octets  long. 
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6.1.1.1.2  R-lnitialize  result 


Table  2  -  Parameters  for  R-lnltialIze  result  response 


Parameter 

rsp 

cnf 

Limitation 

operation!  D 

M 

M(= 
) 

An  INTEGER  with  value  greater  than 
0. 

controlServiceData 

C 

C(= 
) 

See  subparameter(s)  below. 

•controlServicesAllowed 
(default  value:  TRUE) 

M 

M(= 
) 

No  additional  limitation. 

•controlAuthentlcatlon- 
Data 

1 

l(=) 

• 

The  server  may  provide  an  lASString 
from  1  through  255  characters  long, 
an  OCTET  STRING  from  1  through 
255  octets  long,  or  a  BIT  STRING 
from  1  through  2040  bits  long. 

functlonalUnttsAllowed 

M 

M(= 
) 

No  additional  limitation. 

sQUnitializeResult 

U 

C(= 
) 

See  subparameter(s)  below. 

•userData 

1 

l(=) 

An  OCTET  STRING  from  1  through 
255  octets  long. 

6.1.1.1.3  R-lnitialize  error 

Table  3  -  Parameters  for  R-lnitialize  error  response 


Parameter 

rsp 

cnf 

Limitation 

operation!  D 

M 

M(= 
) 

An  INTEGER  with  value  greater  than 
0. 

accessControlViolation 

S 

S(= 
) 

No  additional  limitation. 

duplicateDialoguelD 

S 

S(= 
) 

No  additional  limitation. 

• 

invalidSequence 

S 

See  subp)arameter(s)  below. 

•diagnosticlnformation 

U 

No  additional  limitation. 
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Parameter 

rsp 

cnf 

Limitation 

operatlonAborted 

S 

S(= 
) 

See  subparameter(s)  below. 

•errorType  (defeult 
value:transient) 

M 

M(= 
) 

No  additional  limitation. 

•diagnosticlnformation 

U 

C(= 
) 

A  VisibleString.  from  1  through  254 
characters  long. 

userAuthenticationFailure 

S 

S(= 
) 

No  additional  limitation. 

6.1.1.2        R-Synchronize  APDU 

The  R-Synchronize-Rl  APDU  has  no  parameters. 

6.1.2       Dialogue  termination  functional  unit 


6.1.2.1  R-Termlnate  service 
6.1.2.1.1  R-Terminate  request 


Table  4  -  Parameters  for  R-Terminate  request 


Parameter 

req 

ind 

Limitation 

OperationID 

M 

M(=) 

An  INTEGER  with  value  greater  than  0. 

6.1.2.1.2          R-Terminate  result 

Table  5  -  Parameters  for  R-Terminate  result  response 

Parameter 

rap 

cnf 

Limitation 

operationID 

M 

M(=) 

An  INTEGER  with  value  greater  than  0. 
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6.1.2.1.3  R-Terminate  error 

Table  6  -  Parameters  for  R-Terminate  error  response 


Parameter 

rap 

cnf 

Limitation 

operationIO 

M 

M(  =  ) 

An  INTEGER  with  value  greater  than  0. 

duplicateOperationI  D 

S 

S(=) 

No  additional  limitation. 

invalidSequence 

s 

See  subparameter(s)  below. 

•diagnosticlnfbrmation 

u 

No  additional  limitation. 

operationAborted 

S 

S(=) 

See  8ubparameter(s)  below. 

•errorType(default  value: 
transient) 

M 

M(= 
) 

No  additional  limitation. 

•diagnosticlnformation 

U 

C(= 
) 

A  VisibleString  from  1  through  254 
characters  long. 

serviceNotNegotiated 

S 

S(= 
) 

No  additional  limitation. 

6.1.3       Transaction  management  functional  unit 


6.1.3.1  R-Beginlransaction  service 
6.1.3.1.1  R-BeginTransaction  request 


Table  7  -  Parameters  for  R-BeginTransaction  request 


Parameter 

req 

Ind 

Limitation 

operationID 

M 

M(  =  ) 

An  INTEGER  with  value  greater  than  0. 
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6.1.3.1.2  R-BeginTransaction  error 

Table  8  -  Parameters  for  R-BeginTransaction  error  response 


Parameter 

rsp 

cnf 

Umitation 

operationID 

M 

) 

An  INTEGER  with  value  greater  than 
0. 

duplicateOperationI  D 

S 

S(= 
) 

No  additional  limitation. 

invalidSequence 

S 

See  subparameter(s)  below. 

•diagnostici  nformation 

u 

No  additional  limitation. 

operationAborted 

S 

S(= 

) 

See  subparameter(s)  below. 

•errorType(default  value: 
transient) 

M 

M(= 
) 

No  additional  limitation. 

•diagnostlclnformation 

U 

C(= 
) 

A  VisibleString,  from  1  through  254 
characters  long. 

serviceNotNegotiated 

S 

S(= 
) 

No  additional  limitation. 

6.1.3.2        R-Commit  service 


6.1.3.2.1  R-Commit  request 

Table  9  -  Parameters  for  R-Commit  request 


Parameter 

req 

ind 

Limitation 

operationID 

M 

M(= 
) 

An  INTEGER  with  value  greater  than 
0. 

6.1.3.2.2          R-Commit  result 

Table  10  -  Parameters  for  R-Commit  result  response 

Parameter 

rsp 

cnf 

Limitation 

OperationID 

M 

M(=) 

An  INTEGER  with  value  greater  than  0. 

transactionResult 

M 

M(=) 

No  additional  limitation. 
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6.1.3.2.3  R-Commit  error 

Table  1 1  -  Parameters  for  R-Comm'rt  error  response 


Paramttter 

rsp 

cnf 

Limitation 

operationID 

M 

M(  =  ) 

An  INTEGER  with  value  greater  than  0. 

duplicateOperationlD 

S 

S(=) 

No  additional  limitation. 

invalidSequence 

S 

See  subparameter(s)  below. 

•diagnostidnformation 

u 

No  additional  limitation. 

6.1.3.3        R-Rollback  service 

6.1.3.3.1  R-Rollback  request 

Table  12  -  Parameters  for  R-Rollback  request 


Parameter 

req 

Ind 

Limitation 

operationID 

M 

M(= 
) 

An  INTEGER  with  value  greater  than 
0. 

6.1.3.3.2           R-Rollback  result 

Table  13  -  Parameters  for  R-Rollback  result  response 

Parameter 

rsp 

cnf 

Limitation 

OperationID 

M 

M(  =  ) 

An  INTEGER  with  value  greater  than  0. 

6.1.3.3.3  R-Rollback  error 
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Table  14  -  Parameters  for  R-Rollback  error  response 


Param«t*r 

rsp 

cnf 

Umttation 

operationID 

M 

M(  =  ) 

An  INTEGER  with  value  greater  than  0. 

duplicateOperationlD 

S 

S(=) 

No  additional  limitation. 

invalidSequence 

S 

See  subparameter(s)  below. 

•diagnostidnfbrmation 

u 

No  additional  limitation. 

6.1.4  Cancel  functional  unit 
6.1.4.1        R-Cancel  service 


6.1.4.1.1  R-Cancel  request 

Table  15  -  Parameters  for  R-Cancel  request 


Parameter 

req 

Ind 

Limitation 

operationID 

M 

M(= 

An  INTEGER  with  value  greater  than 
0. 

controlledDialogue 

U 

C(= 

See  subparameter(s)  below. 

•dialogue!  D 

M 

M(= 

See  subparameter(s)  below. 

•  •dialogue!  DCiient- 
Invocation 

U 

C(= 

See  subparameter(s)  below. 

•••aP-title 

M 

M(= 

No  additional  limitation. 

•••aE-quallfier 

M 

M{= 

No  additional  limitation. 

•••aP-invocation!D 

M 

M(= 

No  additional  limitation. 

•••aE-!nvocationlD 

M 

M(= 

No  additional  limitation. 

••dialoguelDSuffix 

1^ 

M(= 

An  OCTET  STRING  from  1  through  64 
octets  long. 
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  — 

Parameter  req 

ind 

Limitation 

•contrdAuthentlcationData 

M 

M(= 
) 

The  client  may  provide  an  lASString 
from  1  tlirough  255  cliaracters  long, 
an  OCTET  STRING  from  1  through 
255  octets  long,  or  a  BIT  STRING 
from  1  to  2040  bits  long. 

listOfOperationID 

— 
U 

C(= 

) 

This  list  may  contain  from  1  through 
32  entries  of  OperationlD. 

•OperatlonID 

C 

C(= 
) 

An  INTEGER  with  value  greater  than 

0. 

6.1.4.1.2  R-Cancei  result 

Table  16  -  Parameters  for  R-Cancei  result  response 


Parameter 

rsp 

cnf 

Limitation 

operationID 

M 

M(=) 

An  INTEGER  with  value  greater  than  0. 

6.1.4.1.3          R-Cancel  error 

Table  17  -  Parameters  for  R-Cancel  error  response 

Parameter 

rsp 

cnf 

Limitation 

operationID 

M 

M(  =  ) 

An  INTEGER  with  value  greater  than  0. 

controlAuthenicationFailure 

8 

S(=) 

No  additional  limitation. 

controlServices- 
NotAllowed 

S 

S(= 

) 

No  additional  limitation. 

dialoguelDUnknown 

S 

S(= 

) 

No  additional  limitation. 

duplicateOperationI  D 

S 

S(= 

) 

No  additional  limitation. 

invalidSequence 

S 

See  subparameter(s)  below. 

•diagnostici  nf  ormation 

u 

No  additional  limitation. 

operationAborted 

S 

S(= 

) 

See  subparameter(s)  below. 
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1  Parameter 

rsp 

cnf 

Umttation 

•errorType  (default  value: 
transient) 

M 

M(= 
) 

No  additional  limitation. 

•diagnosticlnfonnation 

U 

C(= 
) 

A  Visil3leString,  from  1  through  254 
characters  long. 

serviceNotNegotiated 

S 

S(= 
) 

No  additional  limitation. 

6.1.5       Status  functional  unit 


6.1.5.1        R-Status  service 


6.1.5.1.1  R-Status  request 

Table  18  -  Parameters  for  R-Status  request 


Parameter 

req 

ind 

Limitation 

operationID 

M 

M(= 

An  INTEGER  with  value  greater  than 
0. 

controlledDialogue 

U 

C(= 

See  subparameters  below. 

•dialoguelD 

M 

M(= 

See  subparameter(s)  below. 

••dialoguelDCIient- 
Invocation 

U 

C(= 

See  subparameter(s)  below. 

•••aP-title 

M 

M(= 

No  additional  limitation. 

•••aE-qualifier 

M 

M(= 

No  additional  limitation. 

•••aP-invocationID 

1^ 

M(= 

No  additional  limitation. 

•••aE-invocationID 

M 

M(= 

No  additional  limitation. 

••dialoguelDSuffIx 

M 

M(= 

An  OCTET  STRING  from  1  through  64 
octets  long. 
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Parameter 

req 

ind 

Limitation 

•controiAuthenticatlonData 

M 

M(= 
) 

The  client  may  provide  an  lASString 
from  1  through  255  characters  long, 
an  OCTET  STRING  from  1  through 
255  octets  long,  or  a  BIT  STRING 
from  1  to  2040  bits  long. 

1  listOfOperationID 

U 

C(= 
) 

This  list  may  contain  from  1  through 
32  entries  oif  OperationID. 

1  •OperationID 

C 

C(= 

) 

An  INTEGER  with  value  greater  than 

0. 

6.1.5.1.2  R-Statu8  result 

Table  19  -  Parameters  for  R-Status  result  response 


r ""  

Parameter 

rsp 

cnf 

Limitation 

OperationID 

M 

M(=) 

An  INTEGER  with  value  greater  than  0. 

listOfStatuslnfbrmation 

C 

C(=) 

This  list  may  contain  from  1  through  32 
entries  of  Statuslnformation. 

1  •Statuslnfbrmation 

U 

C(=) 

See  subparameter(s)  below. 

••OperationID 

M 

M(=) 

An  INTEGER  with  value  greater  than  0. 

••operationStatus 

M 

M(=) 

See  choice(s)  below. 

•  •  •operationlDUnknown 

S 

8(=) 

No  additional  limitation. 

•  •  •awaitingExecution 

S 

8(=) 

No  additional  limitation. 

•••executing 

S 

8(=) 

No  additional  limitation. 

•••finished 

8 

8(=) 

No  additional  limitation. 

•••cancelled 

S 

S{=) 

No  additional  limitation. 

•••atsorted 

8 

S(=) 

A  VisibleString  with  value  from  1  through 
254  characters  long. 

6.1.5.1.3  R-Status  error 
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Table  20  -  Parameter  for  R-Status  error  response 


Parameter 

rep 

cnf 

Limitation 

operationID 

M 

M(=) 

An  INTEGER  with  value  greater  than  0. 

oontrdAuthenticationFailure 

S 

S(=) 

No  additional  limitation. 

III  WI9VI  vi^^^cr" 

NotAllcwed 

c 
o 

) 

no  aoQiiionai  iimiiciiton. 

HinlfViiiAir)!  Inlfnnutin 

s 

o\- 
) 

oupiicaiev^peiauoni  u 

C 
O 

) 

iNO  aoonionai  iirnnaiion. 

InvalidSequence 

S 

See  subparameter(s)  below. 

•diagnosticlnformation 

U 

No  additional  limitation. 

1  operatlonAborted 

s 

S(= 

) 

See  subparameter(s)  below. 

•errorType 

(default  value:  transient) 

M 

M(= 
) 

No  additional  limitation. 

•diagnostlclnformation 

U 

C(= 
) 

A  VisibleString,  from  1  through  254 
characters  long. 

1  servlceNotNegotlated 

S 

S(= 
) 

No  additional  limitation. 

6.1.6       Resource  handling  functional  unit 


6.1.6.1  R-Open  service 
6. 1 .6. 1 . 1  R-Open  request 
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Table  21  -  Parameters  for  R-Open  request 


1  ParaiTMter 

req 

ind 

Limitation 

1  operationID 

M 

M(=) 

An  INTEGER  with  value  greater  than  0. 

1  dataResourceHandle 

M 

M(=) 

An  INTEGER  with  value  greater  than  0. 

parentDataResourceHandle 

1 

"(=) 

An  INTEGER  with  value  geater  than  0. 

dataResourceName 

U 

C(=) 

A  VisibleString,  from  1  through  254 
characters  long. 

sQLAccessControlData 

1 

l(=) 

The  client  may  provide  an  lASString  from 
1  through  255  characters  long,  an 
OCTET  STRING  from  1  through  255 
octets  long,  or  a  BIT  STRING  from  1 
through  2040  bits  long. 

sOLUsageMode 

U 

C(=) 

No  additional  limitation. 

sQLOpenArgument 

U 

C(=) 

See  subparameter(s)  below. 

•charSet 

U 

C(=) 

An  OBJECT  IDENTIFIER  from  2  through 
16  elements  long. 

•sOLConformanceLevel 

U 

C(=) 

An  OBJECT  IDENTIFIER  from  2  through 
16  elements  long. 
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6.1.6.1.2  R-Open  result 


Table  22  -  Parameters  for  R-Open  result  response 


1  

Parameter 

rsp 

cnf 

Limitation 

operation!  D 

M 

M(= 
) 

An  INTEGER  with  value  greater  than 
0. 

sQLOpenResult 

U 

C(= 
) 

See  subparameter(s)  below. 

•charSet 

u 

C(= 
) 

An  OBJECT  IDENTIFIER  from  2 
through  16  elements  long. 

•charSetNotSupported 
(default  value  :  FALSE) 

u 

C(= 
) 

No  additional  limitation. 

•sQLConfomnanceLevel 

c 

C(= 
) 

An  OBJECT  IDENTIFIER  from  2 
through  16  elements  long. 

6.1.6.1.3  R-Open  error 

Table  23  -  Parameters  for  R-Open  error  response 


Parameter 

rsp 

cnf 

Limitation 

operationID 

M 

M(= 
) 

An  INTEGER  with  value  greater  than 
0. 

dataResourceAlreadyOpen 

S 

S(= 
) 

See  subparameter(s)  below. 

•dataResourceHandle 

M 

M(= 
) 

An  INTEGER  with  value  greater  than 
0. 

dataResourceNameNot- 
Specified 

S 

S(= 
) 

No  additional  limitation. 

dataResourceNotAvailable 

S 

S(= 
) 

See  subparameters  below. 

•errorType  (default  value  : 
transient) 

M 

M(= 
) 

No  additional  limitation. 

1  •diagnosticlnformation 

U 

C(= 
) 

A  VisibleString,  from  1  through  254 
characters  long. 

dataResourceUnknown 

S 

S(= 
) 

No  additional  limitation. 
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Parameter 

rsp 

cnf 

Limitation 

duplicateDataResource- 
Handle 

S 

S(= 
) 

No  additional  limitation. 

duplicateOperationI  D 

S 

S(= 

) 

No  additional  limitation. 

invalidSequence 

s 

See  subparameter(s)  below. 

•diagnosticlnformation 

u 

No  additional  limitation. 

operationAborted 

S 

S(= 

) 

See  subparameter(s)  below. 

•errorType(default  value: 
transient) 

M 

M(= 
) 

No  additional  limitation. 

•diagnostici  nformation 

U 

C(= 
) 

A  VisibleString,  from  1  through  254 
characters  long. 

operationCancelled 

S 

S(= 
) 

No  additional  limitation. 

parentDataResource- 
Unknown 

1 

l(=) 

No  additional  limitation. 

serviceNotNegotiated 

S 

S(= 
) 

No  additional  limitation. 

sQLOpenError 

S 

S(= 
) 

See  choice(s)  below. 

•invalidSQLConfornriance- 
Level 

S 

S(= 

) 

No  additional  limitation. 

•sQLAccessControl- 
Vioiation 

S 

S(= 

) 

No  additional  limitation. 

•sQLDatabaseResource- 
AlreadyOpen 

S 

S(= 

) 

No  additional  limitation. 

•rDATransactionOpen 

S 

S(= 

) 

No  additional  limitation. 

6.1.6.2        R-Close  service 


6.1.6.2.1  R-Close  request 
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Table  24  -  Parameters  for  R-Close  request 


Parameter 

req 

ind 

Limitation 

operationlD 

M 

M(  =  ) 

An  INTEGER  with  value  greater  than  0. 

listOfDataResourceHandle 

U 

C(  =  ) 

This  list  shall  contain  one  entry  of 
DataResourceHandle. 

•DataResourceHandle 

U 

C(=) 

An  INTEGER  with  value  greater  than  0. 

6.1.6.2.2  R-Close  resuK 

  Table  25  -  Parameters  for  R-Close  result  response 


Parameter 

rsp 

cnf 

Limitation 

operationlD 

M 

M(= 

An  INTEGER  vj'fth  value  greater  than 
0. 

listOfCloseExceptions 

U 

C(= 

This  list  shall  contain  one  entry  of 
CloseException. 

•aoseException 

M 

M(= 

See  subparameter(s)  below. 

••dataResourceHandle 

M 

M(= 

An  INTEGER  with  value  greater  than 

0. 

••closeException 

M 

M(= 

See  choice(s)  below. 

•  •  •dataResourceHandle- 
Unknown 

S 

S(= 

No  additional  limitation. 

6.1.6.2.3  R-Close  error 

Table  26  -  Parameters  for  R-Close  error  response 


Parameter 

rsp 

cnf 

Limitation 

operationlD 

M 

M(= 
) 

An  INTEGER  with  value  greater  than 
0. 

duplicateOperation!  D 

S 

S(- 
) 

No  additional  limitation. 

invalidSequence 

S 

See  subparameter(s)  below. 

^ — _ — 
•diagnosticlnformation 

 — 

U 

No  additional  limitation. 
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operationAborted 

S 

S(= 
) 

See  subparameter(s)  below. 

•errorType(default 
value:  transient) 

M 

M(= 

) 

No  additional  limitation. 

•diagnostic!  nf omnation 

U 

C(= 

) 

A  VisibleString,  from  1  through  254 
characters  long. 

operationCancelled 

S 

S(= 

) 

No  additional  limitation. 

serviceNotNegotiated 

S 

S(= 

) 

No  additional  limitation. 

sQLQoseError 

S 

S(= 

) 

See  choice(s)  t>elow. 

•rDATransactionOpen 

S 

S(= 

) 

No  additional  limitation. 

6.1.7       Immediate  execution  DBL  functional  unit 


6.1.7.1         R-ExecuteDBL  service 


6.1.7.1.1  R-ExecuteDBL  request 


L 
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Table  27  -  Parameters  for  R-ExecuteDBL  request 


Parameter 

req 

ind 

Limitation 

operationID 

M 

M(  =  ) 

An  INTEGER  with  value  greater  than  0. 

dataResourceHandle 

U 

C(  =  ) 

An  INTEGER  with  value  greater  than  0. 

sQLDBLStatement 

M 

M(=) 

See  subparameter(s)  below. 

•statementText 

M 

M(  =  ) 

An  OCTET  STRING,  from  1  through  4000 
octets  long. 

•charSet 

U 

C(=) 

An  OBJECT  IDENTIFIER,  from  2  through 
16  elements  long. 

sQLOBLArgument- 
Spedfication 

U 

C(=) 

This  parameter  may  contain  1  through 
100  entries  of  SQLDataTypeDescriptor. 
See  table  39,  Parameters  for 
SQLDataTypeDescriptor. 

sQLOBLResultSpecification 

u 

C(=) 

This  parameter  may  contain  1  through 
100  entries  of  SQLDataTypeDescriptor. 
See  table  39,  Parameters  for 
SQLDataTypeDescriptor. 

dSLArguments 

u 

C(=) 

See  choice(s)  below. 

•singleArgument 

s 

S(=) 

See  subparameter(s)  below. 

•  •repetitionCount(defautt 
value:  1) 

M 

M(=) 

An  INTEGER  with  value  from  1  through 
64. 

•  •sQLDBLArgumentValues 

C 

C(=) 

This  parameter  may  contain  from  1 
through  100  entries  of  SQLValue.  See 
table  41 ,  Parameters  for  SQLValue. 

•multipleArgument 

S(= 
) 

S(=) 

See  subparam6ter(s)  below. 

•  •listOfSQLDBLArgument- 
Values 

M 

M(=) 

This  list  may  contain  from  1  through  64 
entries  of  SQLDBLArgumentValues. 

•  •  •SQLDBLArgumentValues 

C 

C(=) 

This  parameter  may  contain  from  1 
through  100  entries  of  SQLValue.  See 
table  41 ,  Parameters  for  SQLValue. 
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6. 1 .7. 1 .2  R-ExecuteDBL  result 


Table  28  -  Parameters  for  R-ExecuteDBL  result  response 


Parameter 

rsD 

cnf 

Limitation 

operatlonID 

M 

) 

An  INTEGER  with  value  greater  than 

U. 

sQLDBLResult- 
Specificatton 

C 

C(= 
) 

This  parameter  may  contain  1 
through  100  entries  of 
SQLOataTypeDescriptor.  See  table 
39,  Parameters  for 
SQLOataTypeDescriptor. 

listOfResultValues 

U 

C(= 
) 

This  list  may  contain  1  through  64 
entries  of  ResultValues. 

•ResultValues 

M 

M(= 
) 

See  subparameter(s)  below. 

•  •sQLDBLException 

M 

M(= 
) 

See  table  40,  Parameters  for 
SQLDBLException. 

••sQLDBLResultValues 

C 

C(= 
) 

This  parameter  may  contain  1 
through  100  entries  of  SQLValue.  See 
table  41 ,  Parameters  for  SQLValue. 
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6.1.7.1.3  R-ExecuteDBL  error 


Table  29  -  Parameters  for  R-ExecuteDBL  error  response 


Parameter 

rsp 

cnf 

Limitation 

rtnorfltinni  n 

M 

IVI 

""V 

An  INTFf^FR  with  x/aliiP  nroAtPr  tlinn 

r^i  1  11^  1  ^N^L^ri  Will  1  VGiiuo  ui  cciid  ii  icii  i 

0. 

badRepetitionCount 

S 

S(= 
) 

No  additional  limitation. 

dataResourceHandle- 
NotSpecified 

s 

S(= 

) 

No  additional  limitation. 

dataResourceHandle- 
Unknown 

s 

S(= 

) 

No  additional  limitation. 

duplicateOperationID 

s 

S(= 

) 

No  additional  limitation. 

invalkJSequence 

s 

See  subparameter(s)  below. 

•diaano^icl  nformation 

u 

No  additional  limitation 

noDataResourceAvailable 

s 

S(= 

\ 
1 

No  additional  limitation. 

operationAborted 

s 

S(= 
\ 

1 

See  subparameter(s)  below. 

•errorType(default  value: 
transient) 

M 

M(= 

\ 
I 

No  additional  limitation. 

•diagnostici  nf  ormation 

U 

C(= 
) 

1 

A  VisibleStrlng.  from  1  through  254 
characters  lona 

lUI  U^iwl  w  l^^l  'a* 

operationCancelled 

S 

S(= 

) 

No  additional  limitation. 

sen/iceNotNegotiated 

s 

S(= 

) 

No  additional  limitation. 

transactionRolledBack 

s 

S(= 

) 

No  additional  limitation. 

sQLExecuteDBLError 

s 

S(= 

) 

See  choice(s)  below. 

•sQLUsageModeViolation 

s 

S(= 

) 

No  additional  limitation. 

•sQLDBLTransaction- 
StatementNotAllowed 

s 

S(= 

) 

No  additional  limitation. 

25 


Part  19  •  Remote  Database  Access 


December  1992  (Stable) 


Parameter 

rsp 

cnf 

Umitation 

•sQLDBLArgumentCount- 
Mismatch 

S 

S(= 
) 

No  additional  limitation. 

r~  

•sQLDBLArgumentType- 
Mismatch 

S 

S(= 

) 

No  additional  limitation. 

•sQLDBLNoCharSet 

s 

S(= 

) 

No  additional  limitation. 

•hostldentifierError 

s 

S(= 

) 

No  additional  limitation. 

1  •rOATransactionNotOpen 

s 

S(= 

) 

No  additional  limitation. 

6.1.8       Stored  Execution  DBL  Functional  Unit 
6.1.8.1        R-DefineDBL  Service 
6. 1 .8. 1 . 1  R-DeflneDBL  request 


Table  30  -  Parameters  for  R-DeflneDBL  request 


1  Parameter 

req 

ind 

Umitation 

operationID 

M 

M(= 
) 

An  INTEGER  with  value  greater  than 
0. 

commandHandle 

M 

M(= 
) 

An  INTEGER  with  value  greater  than 
0. 

dataResourceHandle 

U 

C(= 
) 

An  INTEGER  with  value  greater  than 
0. 

sQLDBLStatement 

M 

M(= 
) 

See  subparameter(s)  t)eiow. 

•statementText 

M 

M(= 
) 

An  OCTET  STRING  from  1  through 
4000  octets  long. 

•charSet 

U 

C(= 
) 

An  OBJECT  IDENTIFIER  from  2 
through  16  elements  long. 

26 


Part  19  -  Remote  Database  Access 


December  1992  (Stable) 


sQLDBLArgument- 
Specification 

U 

C(= 
) 

This  parameter  may  contain  1 
tlirough  100  entries  of 
SQUDataTypedescrlptor.  See  table  39, 
Parameters  for 
SQi-DataTypeDescrlptor. 

sQLDBLResult- 
Specification 

U 

C(= 

) 

Tliis  parameter  may  contain  1 
through  100  entries  of 
SQI-DataTypeDescrlptor.  See  table 
39,  Parameters  for 
SQLDataTypeDescriptor. 

6. 1 .8. 1 .2           R-Def ineDBL  result 

Table  31  -  Parameters  for  R-Def  IneDBL  result 

Parameter 

res 

cnf 

Limitation 

op>erationlD 

M 

M(= 
) 

An  INTEGER  with  value  greater  than 
0. 

sQLDBLResult- 
Specification 

C 

C(= 
) 

This  parameter  may  contain  1  through 
100  entries  of 

SQLDataTypeDescriptor.  See  table 
39,  Parameters  for 
SQLDataTypeDescriptor. 

sQLDBLException 

C 

C(= 
) 

See  table  40,  Parameters  for 
SQLDBLException. 

6. 1 .8. 1 .3           R-Def  ineDBL  error 

Table  32  -  Parameters  for  R-DefineDBL  error 

Parameter 

rsp 

cnf 

Limitation 

operationID 

M 

M(= 
) 

An  INTEGER  with  value  greater  than 
0. 

dataResourceHandle- 
NotSpecified 

S 

S(= 
) 

No  additional  limitation. 

dataResourceHatxile- 
Unknown 

S 

S(= 
) 

No  additional  limitation. 

duplicateCommandHandle 

S 

S{= 
) 

No  additional  limitation. 
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rep 


cnf 


duplicateOperatioolD 


No  addltionaS  limitatton. 


invedidSequence 


S 


See  SL8bparameter(s)  below. 


•diagnosticlnfornriation 


U 


No  additional  iimttatlon. 


noDataResourceAvaiiable 


S(= 


No  additionai  limitation. 


operationAborted 


S(= 


See  subparameter(s)  below. 


•erTorType(defauit  value: 
transient) 


M 


No  additional  limitation. 


•diagnosticinformatlon 


U 


C(= 


A  VisibieString,  from  1  through  254 
characters  long. 


operationCancelled 


S(= 


No  additional  limitation. 


serviceNotNegotiated 


S(= 


No  additional  limitation. 


sQLDefineDBLError 


Si- 


See  choice(s|  below. 


.sQLDBLNoCharSet 


No  additional  limitation. 


•sQLDBLTransaction- 
StatementNotAllowed 


No  additional  limitation. 


•sQLUsageModeViolation 


Si- 


Mo  additional  limitation. 


•hostSdentiierError 


No  additional  limitation. 


6.1.8.2 


R-lnvokeDBL  Service 


6.1.8.2.1 


R-lnvokeDBL  request 


Table  33  -  Parametere  for  R-lnvokeDBL  request 


Parameter 


req 


irsd 


Limitation 
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1  operationID 

M 

— ~— 
M(= 
) 

An  INTEGER  with  value  greater  than 
0 

commandHandle 

M 

M(= 
) 

An  INTEGER  with  value  greater  than 
0. 

dBLArguments 

U 

C(= 

) 

See  cholce(s)  t>elow. 

1  •singleArgument 

S 

S(= 

) 

See  subparameter(s)  below. 

1  ••repetitionCount 
1  pefault  Value:  1) 

M 

M(= 
) 

An  INTEGER  with  value  from  1 
through  64. 

••sQLDBLArgumentValues 

C 

C(= 
) 

This  parameter  may  contain  1  through 
100  entries  of  SQLValue.  See  table 
41 ,  Parameters  for  SQLValue. 

•multipleArgument 

S 

S(= 
) 

See  subparameter(s)  below. 

•  •listOf  SQLDBLArgument- 
Values 

M 

M(= 
) 

This  list  may  contain  1  through  64 
entries  of  SQLDBLArgumentValues. 

•••SQLDBLArgument- 
Values 

C 

C(= 
) 

This  parameter  may  contain  1  through 
100  entries  of  SQLValue.  See  table 
41,  Parameters  for  SQLValue. 

6.1.8.2.2  R-lnvokeDBL  result 


Table  34  -  Parameters  for  R-lnvokeDBL  result 


Parameter 

res 

cnf 

Limitation 

operationID 

M 

M(= 
) 

An  INTEGER  with  value  greater  than 
0. 

sQLDBLResult- 
Specificatlon 

C 

C(= 
) 

This  parameter  may  contain  1  through 
100  entries  of 

SQLDataTypedescriptor.  See  table  39, 
Parameters  for 
SQLDataTypeDescriptor. 

listOfResultValues 

M 

M(= 
) 

This  list  may  contain  1  through  64 
entries  of  ResultValues. 

•ResultValues 

M 

M(= 
) 

See  subparameter(s)  below. 
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•  •sQLDBLException 

M 

M(= 
) 

See  table  40,  Parameters  for 
SQLDBLException. 

••sQLDBLResultValues 

C 

C(= 
) 

This  parameter  may  contain  1  through 
100  entries  of  SQLValue.  See  table 
41 ,  Parameters  for  SQLValue. 

6.1.8.2.3           R-lnvokeDBL  error 

Table  35  -  Parameters  for  R-lnvokeDBL  error 

Parameter 

rsp 

cnf 

Limitation 

opeiaiiuni 

M 

iVl 

[VI  ^  — 
) 

Mn  MM  1  cocn  Willi  vciilk?  yrtTcti^r  iiidii 
0. 

uaunepeiiiiunv,A?uni 

e 
o 

) 

rMO  aCjQIllOnal  lliTlllallOn. 

cornrnaria  nanoi  eu  n  Known 

e 
o 

b(= 
) 

NO  aoonionai  iimnaiion. 

aupiicateuperationiu 

e 
o 

S(= 
) 

No  additional  limitation. 

invalidSequence 

s 

See  subparameter(s)  below. 

•diagnosticlnformation 

u 

No  additional  limitation. 

operationAborted 

S 

S(= 

) 

See  subparameter(s)  below. 

•errorType(default  value: 
transient) 

M 

M(= 
) 

No  additional  limitation. 

•diagnosticlnformation 

U 

C(= 
) 

A  VisibleString,  from  1  through  254 
characters  long. 

operationCancelled 

S 

S(= 
) 

No  additional  limitation. 

serviceNotNegotiated 

S 

S(= 
) 

No  additional  limitation. 

transactionRolledSack 

S 

S(= 
) 

No  additional  limitation. 

sQUnvokeDBLError 

s 

S(= 

) 

See  choice(s)  below. 
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Parameter 

rap 

cnf 

Limitation  | 

•sQLUsageModeViolatlon 

S 

S(= 
) 

No  additional  iimitation.  1 

•sQLOBLArgumentType- 
Mismatch 

S 

S(= 

) 

No  additional  iimitatton.  1 

•sQLOBLArgumentCount- 
Mismatch 

s 

S(= 

) 

No  additional  limitation. 

•rOATransactionNotOpen 

s 

S(= 

) 

No  additional  limitation.  | 

6.1.8.3  R-DropDBL  Service 
6.1.8.3.1  R-DropDBL  request 


Tabie  36  -  Parameters  for  R-DropDBL  request 


Parameter 

req 

ind 

Limitation 

operatlonID 

M 

M(= 
) 

An  INTEGER  with  value  greater  than 
0. 

listOfCommandHandle 

U 

C(= 
) 

This  list  may  contain  from  1  through 
32  entries  of  CommandHandle. 

•CommandlHandle 

C 

C(= 
) 

An  INTEGER  with  value  greater  than 
0. 

6.1.8.3.2  R-DropDBL  result 


Table  37  -  Parameters  for  R-DropOBL  result 


Parameter 

res 

cnf 

Limitation 

operationID 

M 

M(= 
) 

An  INTEGER  with  value  greater  than 
0. 

llstOfDropDBLExceptions 

U 

C(= 
) 

This  list  may  contain  1  through  32 
entries  of  DropDBLException. 

•DropOBLException 

M 

M(= 
) 

See  subparameter(s)  below. 
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••commandHandle 

M 

M(= 
) 

An  INTEGER  with  value  greater  than 
0. 

••dropDBLExceptlon 

M 

M(= 
) 

See  subparameter(s)  below. 

•••commandHandie- 
Unknown 

S 

S(= 

) 

No  additional  limitation. 

6.1.8.3.3           R-DropDBL  error 

Table  38  -  Parameters  for  R-DropDBL  error 

Parameter 

rap 

cnf 

Limitation 

operationIO 

M 

M(= 
) 

An  INTEGER  with  value  greater  than 
0. 

duplicateOperationlD 

S 

S(= 
) 

No  additional  limitation. 

invalidSequence 

S 

See  subparameter(s)  below. 

•diagnostici  nformation 

u 

No  additional  limitation. 

operationAborted 

S 

S(= 

) 

See  subparameter(s)  below. 

•errorType(default  value: 
transient) 

M 

M(= 
) 

No  additional  limitation. 

•diagnosticinfomnation 

U 

C(= 
) 

A  VisibleString,  from  1  through  254 
characters  long. 

operationCancelled 

S 

S(= 
) 

No  additional  limitation. 

sen/iceNotNegotiated 

S 

S(= 
) 

No  additional  limitation. 
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6.2      Limits  for  common  parameters 

This  clause  describes  the  parameters  of  the  common  RDA  Types,  those  shared  by  more  thar>  one  RDA 
Service. 

Table  39  describes  the  parameters  for  SQI-DataTypeDescriptor. 
Table  40  describes  the  parameters  for  SQLDBLException. 

Table  41  describes  the  parameters  for  SQLVaiue.  The  range  of  values  for  each  type  of  dataltem  in  this 
table  is  implied  by  the  values  of  the  parameters  of  the  corresponding  type  of  SQLDataTypeDescriptor  in 
Table  39. 


6.2.1  SQLDataTypeDescriptor 


Table  39  -  Parameters  for  SQLDataTypeDescriptor 


Parameter 

req 

ind 

rsp 

cnf 

Limitation 

nuilable  (default 
value:  true) 

M 

M(= 
) 

No  additional  limitation. 

colName 

M 

M(= 
) 

A  VisibleString,  from  1 
through  18  characters 
long. 

typeDescriptor 

M 

M(=) 

M 

M(= 
) 

See  choice(s)  below. 

•characterType 

S 

S(=) 

8 

8(=) 

See  subparameter(s) 
below. 

••charSet 

U 

C(=) 

U 

C(=) 

An  OBJECT  IDENTIFIER, 
from  2  through  16 
elements  long. 

••length 

M 

M(=) 

M 

M(= 
) 

An  INTEGER  with  value 
from  1  through  240.  It 
represents  the  maximum 
number  of  characters  in 
the  data  value.  Trailing 
(padded)  spaces  are 
included  in  the  length,  but 
a  trailing  null  byte  is  not. 

••fixedLength- 

Encoding 

M 

M(=) 

M 

M(= 
) 

No  additional  limitation. 

•numericType 

8 

S(=) 

8 

S(=) 

See  subparameter(s) 
below. 
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1  Parameter 

req 

ind 

rsp 

cnf 

Umitation  | 

1  ••precision 

M 

M(=) 

M 

M(= 
) 

This  parameter  shall  | 
contain  a  value  within  the 
range  of  1  through  15. 

••scale 

M 

M(=) 

M 

M(= 
) 

This  parameter  shall 
contain  a  value  within  the 
range  of  0  through  the 
value  of  precision. 

•decimalType 

S 

S(=) 

S 

S(=) 

See  subparameter(s) 
below. 

••precision 

M 

M(=) 

M 

M(= 
) 

This  parameter  shall 
contain  a  value  within  the 
range  of  1  through  15. 

••scale 

M 

M(=) 

M 

M(= 
) 

This  parameter  shall 
contain  a  value  within  the 
range  of  0  through  the 
value  of  precision. 

•integerType 

S 

S(=) 

S 

S(=) 

See  subparameter(s) 
t}elow. 

••precision 

M 

M(=) 

M 

M(= 
) 

If  precisionBase  is 
decimal,  precision  must 
be  in  the  range  1  through 
9.  If  precisionBase  is 
binary,  precision  must  be 
in  the  range  1  through  31. 

••precisionBase 

M 

M(=) 

M 

M(= 

) 

No  additional  limitation. 

•smaillntType 

S 

S(=) 

S 

S(=) 

See  subparameter(s) 
below. 

••precision 

M 

ft  a  /  V 

M(=) 

M 

a  a  / 

M(= 
) 

If  precisionBase  is 
decimal,  precision  must 
be  in  the  range  1  through 
4.  If  precisionBase  is 
binary,  precision  must  be 
in  the  range  1  through  15. 

••precisionBase 

M 

M(=) 

M 

M(= 
) 

No  additional  limitation. 

•floatType 

S 

S(=) 

S 

S(=) 

See  subparameter(s) 
iDelow. 
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Parameter 

req 

ind 

rsp 

cnf 

Limitation 

••mantissa- 
Precision 

M 

M(=) 

M 

M(= 

An  iNTEGER  with  value 
from  1  tlirougli  20. 

••maxExponent 

M 

M(=) 

M 

M(= 

An  iNTEGER  with  value 
from  0  through  38. 

•realType 

S 

S(=) 

S 

S(=) 

See  subparameter(s) 
below. 

••mantissa- 
Precision 

M 

M(=) 

M 

M(= 

) 

An  INTEGER  with  value 
from  1  through  20. 

••maxExponent 

1^ 

M(=) 

1^ 

M(= 

) 

An  INTEGER  with  value 
from  0  through  38. 

•double- 
PrecisionType 

S 

S(=) 

S 

S(=) 

See  subparameter(s) 
below. 

••mantissa- 
Precision 

M 

M(=) 

M 

M(= 
) 

An  INTEGER  with  value 
from  1  through  30. 

••maxExponent 

M 

M(=) 

M 

M(= 
) 

An  INTEGER  with  value 
from  0  through  38. 

6.2.2  SQLDBLException 

  Table  40  -  Parameters  for  SQLDBLException 


Parameter 

rsp 

cnf 

Limitation 

sQLSTATE 

C 

C(=) 

No  additional  limitation. 

sQLCOOE 

C 

C(=) 

No  additional  limitation. 

sQl^rrorText 

u 

C(=) 

A  VisibleString  from  1  through  254 
characters  long. 

6.2.3  SQLValue 


35 


Part  19  -  Remote  Database  Access  December  1992  (Stable) 


Table  41  -  Parameters  for  SQLValue 


Parameter 

req 

ind 

rsp 

cnf 

Limitation 

dataltem 

U 

C(=) 

u 

C(= 

) 

See  choice(s)  below. 

•characterltem 

S 

S(=) 

s 

S(=) 

An  OCTET  STRING  from 
1  through  240 

cnaraCiors. 

•numericltem 

s 

S(=) 

s 

S(=) 

An  INTEGER  with 
absolute  value  less  than 
10**15.  Note  that  the 
maximum  requires  a  7- 
octet  INTEGER  value. 

•decimalltem 

s 

S(=) 

s 

S(=) 

An  INTEGER  with 
absolute  value  less  than 
10**15.  Note  that  the 
maximum  requires  a  7- 
octet  INTEGER  value. 

•integerltem 

s 

S(=) 

s 

S(=) 

An  INTEGER  with 
absolute  value  less  than 
10**9,  if  precisionBase  is 
decimal.  An  INTEGER 
with  absolute  value  less 
than  2**31,  if 
precisionBase  is  binary. 

•smalllntltem 

s 

S(=) 

s 

S(=) 

An  INTEGER  with 
absolute  value  less  than 
10**4,  if  precisionBase  is 
decimal.  An  INTEGER 

\A/ith  aKcrxliito  locc 

than  2**15,  if 
precisionBase  is  binary. 

•floatltem 

s 

S(=) 

s 

S(=) 

A  REAL  with  the  value  0 
or  absolute  value  in  the 
range  10**-38  through 
10**38  inclusive. 

•realltem 

s 

S(=) 

s 

S(=) 

A  REAL  with  the  value  0 
or  absolute  value  in  the 
range  10**-38  through 
10**38  inclusive. 
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1  Parameter 

req 

ind 

rsp 

cnf 

Limitation 

1  •doubie- 

1  Preclstonltem 

S 

S(=) 

S 

S(=) 

A  REAL  with  the  value  0 
or  absolute  value  in  the 
range  10**-38  through 
10**38  inclusive. 

1  indicator 

U 

C(=) 

U 

C(= 
) 

No  additional  limitation. 

6.3     Other  limits  and  agreements 


6.3.1       Operation  limits  and  agreements 

Operation  limits  and  agreements  follow: 

a)  OlW-compliant  RDA  implementations  shall  conform  to  the  following  agreements  stated  in  part 
5,  Upper  layers: 

1)  the  specific  ASE  requirements  stated  in  clause  13.8,  Remote  Database  Access;  and 

2)  all  other  agreements  that  pertain  to  the  Association  Control  Service  Element, 
Presentation,  and  Session,  including  those  for  ASN.l  encoding; 

b)  OiW-compliant  RDA  implementations  shall  be  able  to  process  at  a  minimum  RDA  Application 
Protocol  Data  Units  of  30,000  octets.  It  is  recommended,  however,  that  Presentation  user  data  not 
be  restricted  in  size; 

c)  The  maximum  number  of  outstanding  RDA  operations  is  32; 

d)  If  an  RDA  sender  receives  an  abort  event  after  an  R-BeginTransaction  indication  and  before  an 
R-Commit  indication,  then  it  should  roll  back  the  current  transaction; 

e)  As  a  minimum,  the  character  set  ISO  8859-1  shall  be  supported.  The  OlW-deflned  object 
identifier  for  this  character  set  is  : 

{  iso  (1)  identified-organization  (3)  oiw  (14) 
rda-sig  (9)  character-sets  (1)  oiw-latin-1  (1)  abstract-syntax  (1)  } 

NOTE  -  This  object  identifier  will  be  deprecated  at  such  time  that  ISO  defines  an  object  identifier  for  ISO  8859- 
1. 
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An  implementation  should  document  any  limitation  on  the  numt^er  of  schema  statements  that  the  server 
permits  within  a  single  transaction.  For  maximum  interoperability,  a  client  should  r^er  mix  schema 
statements  and  data  statements  within  a  transaction  arxJ  should  restrict  the  number  of  schema  statements 
within  a  transaction  to  one. 


6.4     Rules  for  Profiles 

An  implementation  conformant  to  a  profile  shall  implement  all  the  functional  units  of  that  profile;  it  may 
additionaily  implement  other  functional  units  without  being  nonconformant. 

If  a  functional  unit  is  included  in  a  profile,  all  the  services  of  that  functional  unit,  as  specified  in  the  ISO/IEC 
9579-1  and  9579-2,  shall  be  included. 

An  implementation  confomfiing  to  a  given  profile  may  accept  a  dialogue  whose  functional  units  conform  to 
a  different  profile  without  Iseing  nonconformant. 


6.4.1       Application  contexts 

This  sutx^lause  specifies  agreements  that  apply  to  individual  application  contexts. 


6.4.1.1        RDA  basic  application  context 

This  subclause  specifies  agreements  that  apply  to  the  RDA  Basic  Application  Context. 


6.4.1.2  Profiles 

This  subclause  specifies  which  functional  units  combine  to  form  each  profile. 


6.4.1.2.1  Rationale 

The  minimum  requirement  is  to  be  abie  to  execute  SQL  Statements.  Therefore  all  profiles  include  the 
"Immediate  Execution  DBL"  functional  unit,  and  one  profile  (Immediate  Execution)  includes  just  this  minimum 
capability. 

Additional  capabilities  may  t>e  required  for  defining  and  invoking  DBL  statements.  Therefore  the  'Stored 
Execution  DBL"  functional  unit  is  required  only  in  a  separate  profile  (Stored  Execution)  defined  specifically 
for  this  capability. 

For  the  RDA  Control  Services,  executing  control  sen/ices  on  the  current  dialogue  requires  different  and 
probably  simpler  capabilities  than  executing  control  services  on  other  dialogues.  Therefore  additional  profiles 
are  defined  for  controlling  other  dialogues. 
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The  R-Status  Service  implies  only  inquiry  about  the  controlied  dialogue,  while  the  R-Cancel  Service  requires 
the  ability  to  modify  the  controlled  dialogue.  Since  different  authorization  or  access  control  permissions  may 
be  required,  it  is  useful  to  separate  R-Status  from  R-Cancel.  Therefore  two  separate  profiles  (Status  and 
Cancel)  are  defined  for  controlled  dialogue  capat)ilities. 

Since  an  implementation  may  include  functional  units  arxi  services  beyond  those  required,  only  this 
minimum  set  of  four  profiles  is  defined. 

6.4.1.2.2  Immediate  Execution 

This  profile  requires  support  of  immediate  execution  of  SQL  Statements,  it  requires  tlie  foilowing  functional 
units: 

a)  dialogue  initialization; 

b)  dialogue  termination; 

c)  transaction  management; 

d)  resource  handling:  and 

e)  immediate  execution  DBL 

6.4.1.2.3  Stored  execution 

This  profile  requires  support  of  execution  of  stored  SQL  Statements.  It  requires  the  foilowing  functional 
untts: 

a)  dialogue  initialization; 

b)  dialogue  termination; 

c)  transaction  management; 

d)  resource  handling; 

e)  immediate  execution  DBL;  and 

f)  stored  execution  DBL 

6.4.1.2.4  Status 

This  profile  requires  support  of  the  R-Status  service  on  other  dialogues.  It  requires  the  foilowing  functional 
units: 

a)  dialogue  initialization,  specifically  including  the  following  parameters: 
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1)  controlServiceDataRequested;  and 

2)  controiServiceOata; 

b)  dialogue  termination; 

c)  transaction  management; 

d)  status,  specificaliy  including  the  foliowing  parameters: 

1)  controiiedDiaiogue; 

e)  resource  handiing;  and 

f)  immediate  execution  DBL 

6.4.1.2.5  Cancel 

This  profile  requires  support  of  the  R-Cancel  service  on  other  dialogues.  It  requires  the  following  functional 
units: 

a)  dialogue  initialization,  specifically  including  the  following  parameters: 

1)  controlServiceDataRequested;  and 

2)  controlSen/iceData; 

b)  dialogue  tennlnation; 

c)  transaction  management; 

d)  cancel,  specifically  including  the  following  parameters: 

1)  controiiedDiaiogue; 

e)  resource  handling;  and 

f)  immediate  execution  DBL 

6.4.2       RDA  TP  application  context 

No  text. 
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Annex  A  (normative)  

RDA  SIG  object  identifiers 

Table  42  lists  the  object  Identlflers  defined  by  this  part  of  the  Implementation  Agreements. 
 Table  42  -  Object  Mentlfleit  defined  by  RDA 


1                Object  Identifier 

Reference 

iso  (1)  identifled-organization  (3)  oiw  (14) 
rda-sig  (9)  character-sets  (1)  oiw-latin-1  (1) 
at>stract-syntax  (1) 

6.3.1 
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Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Manufacturing  Message 
Specification  (MMS)  Special  Interest  Group  (MMSSIQ)  of  the  Open  Systems  Environment  Implementors' 
Workshop  (OIW).  See  Procedures  Manual  for  Workshop  charter. 

Text  in  this  part  has  been  approved  by  the  Plenary  of  the  above-mentioned  Workshop.  No  significant 
technical  change  has  occurred  in  this  part  since  it  was  previously  presented. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  change 
pages.  Deleted  and  replaced  text  will  be  shown  as  strikeout.  New  and  replacement  text  will  be  shown  as 
shaded. 
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Part  20  -  Manufacturing  Message  Specification  (MMS) 


0  Introduction 

This  section  defines  implementors  Agreements  based  on  Manufacturing  Message  Specification  (MMS),  as 
defined  in  ISO/IEC  9506.  ISO/iEC  9506  lias  two  parts.  Part  1  defines  the  Virtual  Manufacturing  Device 
(VMD).  its  subordinate  at)stract  objects,  and  the  services  on  these  objects.  Part  2  defines  the  protocol. 
Future  parts  may  define  companion  standards. 

MMS,  as  described  in  ISO/IEC  9506,  Is  based  on  the  following  ISO  documents:  ACSE  Service  and  Protocol 
(ISO  8649.  ISO  8650).  Presentation  Service  and  Protocol  (ISO  8822.  ISO  8823),  ASN.1  Abstract  Syntax 
Notation  and  Basic  Encoding  Rules  (ISO  8824.  ISO  8825),  and  Session  Service  and  Protocol  (ISO  8326.  ISO 
8327).  These  services  and  protocols  are  defined  architecturally  in  the  OSI  Reference  Model  (ISO  7498). 
These  agreements  provide  detailed  guidance  for  the  implementor,  and  eliminate  ambiguities  in 
interpretations. 

An  A-Profile  based  on  MMS  and  these  agreements  can  be  used  over  any  T-Profile  (see  ISO  TR  10000) 
specifying  the  OSI  connection-mode  transport  service,  or  the  transport  profiles  used  In  support  of  MAP 
(Manufacturing  Automation  Protocol).  TOP  (Technical  and  Office  Protocols),  or  US  GOSIP. 


1  Scope 


2    Field  of  Application 


2.1  General 

Work  on  implementation  agreements  will  proceed  in  phases  based  upon  grouping  of  services  and/or 
contexts.  Implementations  are  not  constrained  from  implementing  services  or  contexts  not  addressed  by 
the  current  set  of  stable  agreements.  Future  phases  of  work  may  affect  such  Implementations. 


2.2      Phase  1  agreements 

These  agreements  will  be  based  on  a  subset  of  MMS  services  and  protocol  listed  in  table  1  and  defined  in 
ISO/IEC  9506-1  and  ISO/IEC  9506-2. 
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Table  1  -  Phase  1  Services 


Initiate 
Conclude 
Reject 
Abort 

Status 

GetNameList 

Identify 

UnsolicitedStatus 
Ge t Capab i 1 i t yL i s t 

Ini  t  iateDownloadSequence 

DownloadSegment 

Termi  na t  eDownloadSequence 

InitiateUploadSequence 

UploadSegment 

TerminateUploadSequence 

DeleteDomain 

Ge tDomai nAt t r i bu t es 

Read 
Write 

InformationReport 
GetVariableAccessAt tributes 

Input 
Output 

CreateProgramlnvocat  ion 

DeleteProgramlnvocat  ion 

Start 

Stop 

Resume 

Reset 

Kill 

GetProgramlnvocationAttributes 
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3  Normative  References 

[1]       ISO/IEC  9506-1 : 1 990  -  Industrial  automation  systems  -  Manufacturing  Message  Specification  Part 
1:  Service  definition 

[2]      ISO/IEC  9506-2: 1 990  -  Industrial  automation  systems  -  Manufacturing  Message  Specification  Part 
2:  Protocol  specification 

4  Definitions 

The  definitions  given  in  ISO/IEC  9506-1  are  applicable  to  this  document. 
In  addition  the  following  definitions  are  used  in  this  document: 

MMS  Implementation  a  term  used  to  describe  a  system  which  conforms  to  ISO/IEC  9506,  acting 
either  as  client  or  server,  when  it  is  unnecessary  to  distinguish  between  the  MMS-user 
and  the  MMS-provider. 

MMSpdu  Any  valid  value  of  the  MMSpdu  abstract  data  type  as  defined  in  Qause  7  of  ISO/IEC 

9506-2,  except  for  the  initlate-RequestPDU,  initiate-ResponsePDU.  and  initiate-En-orPDU 
choices,  encoded  in  the  negotiated  transfer  syntax. 

5  Corrigenda  and  addenda 

(Refer  to  Working  Agreements.) 


6  Status 

(Refer  to  Working  Agreements.) 


7    General  agreements 


7.1      Max  supported  PDU  size 

The  max_mms_pdu_size  is  defined  as  the  maximum  number  of  octets  in  an  MMSpdu  encoded  using  the 
negotiated  transfer  syntax.  This  size  shall  apply  to  all  MMSpdu's  with  the  exception  of  the  initiate-Request 
PDU,  initiate-Response  PDU,  and  initiate-Error  PDU.  The  max  mms  pdu  size  shall  be  negotiated  during 
connection  initiation  using  the  Local  Detail  Calling  and  Local  Detail  Called  parameters  of  the  MMS  initiate 
service. 

The  negotiated  max_mms_pdu_size  shall  be  applied  as  follows: 
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a)  Any  received  MMSpdu  whose  length  is  less  than  or  equal  to  the  negotiated  nfiax_mms_pdu_size 
shall  tie  property  parsed  and  processed. 

b)  An  MMS  implementation  should  not  send  an  MMSpdu  whose  size  exceeds  the  negotiated 
nnax_mms_pdu_size.  If  an  MMS  implementation  sends  an  MMSpdu  that  exceeds  the  negotiated 
max_mms_pdu_size,  then  it  shall  be  prepared  to  receive  a  reject  pdu.  Should  an  MMS 
implementation  receive  an  MMSpdu  that  exceeds  the  negotiated  max_mms_pdu_size,  it  shall  either 
reject  the  MMSpdu  or  accept  the  MMSpdu  as  if  no  size  violation  had  occurred  and  perform  the 
expected  processing. 

c)  If  an  MMS  implementation  is  unabie  to  send  a  service  response  t>ecause  the  response  would 
exceed  the  max_mms_pdu_size,  then  it  shall  return  a  Service  response  (-)  with  an  error  class  of 
SERVICE  and  an  en-or  code  of  OTHER. 

d)  When  rejecting  an  MMSpdu  because  it  exceeds  the  negotiated  max_mms_pdu_size,  an  MMS 
implementation  shall  use  a  Reject  PDU  Type  of  PDU-ERROR  and  a  Reject  Code  of  INVALID-PDU 
in  the  resulting  reject  pdu. 


7.2  FileName 

Restrictions  for  the  use  of  the  type  FileName  in  the  MMS  Abstract  Syntax  are  specified  in  section  9.1  of  part 
9  of  these  agreements. 


8    Service-specific  agreements 


8.1      Environment  and  generai  management 


8.1.1  Initiate 


8.1 .1 .1        Negotiation  of  MMS  abstract  syntaxes 

On  the  A-ASSOCIATE  response,  the  MMS  responder  shall  not  accept  more  than  one  presentation  context 
derived  from  an  MMS  abstract  syntax.  For  this  agreement,  the  term  "MMS  abstract  syntax"  shall  represent 
an  abstract  syntax  from  the  set  containing  the  abstract  syntax  defined  in  clause  19  of  ISO/IEC  9506-2  and 
abstract  syntaxes  defined  by  MMS  companion  standards. 

NOTE  -  There  are  technical  problems  with  describing  operation  in  multiple  MMS  abstract  syntaxes  over  a 
single  association.  These  problems  have  been  identified  as  of  9/90,  and  form  the  basis  of  the  prior  agreement. 
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8.1 .1 .2        lyiax  serw  ©utstanciiiig 

An  MMS  Implementation  which  intends  to  conform  only  with  the  Obnt  Confomiance  Requirements  for 
Requester  CBBs  shall: 

a)  propose  one  or  greater  for  the  value  of  the  Proposed  Max  Serv  Outstanding  Called  parameter 

in  the  Initiate  service  when  initiating  the  application  association  (calling); 

b)  offer  one  or  greater  for  the  value  of  the  Negotiated  Max  Serv  Outstanding  Calling  parameter  in 
the  Initiate  service  when  receiving  the  application  association  initiation  (called). 

An  MMS  Implementation  which  intends  to  coriorm  to  on®  or  mor@  Server  Confomnance  Requirements  for 
Responder  CBBs  shali: 

a)  propose  one  or  greater  for  the  value  of  the  Proposed  Max  Serv  Outstanding  Calling  parameter 
in  the  Initiate  service  when  initiating  the  application  association  (calling); 

b)  offer  one  or  greater  for  the  value  of  the  Negotiated  Max  Serv  Outstanding  Called  parameter  in 
the  Initiate  service  when  receiving  the  application  association  initiation  (called). 


8.1.1.3        Local  detail  calling 

The  local  detail  calling  parameter  in  the  initiate  request  primitive  shall  specify  the  n^  mms  pdu  size 
guaranteed  to  be  supported  by  the  calling  MMS  implementation.  If  the  local  detail  calling  parameter  is 
absent  from  the  request  primitive,  then  the  calling  MMS  implementation  guarantees  support  for  an  unlimited 

max_mnris__^u_size. 

if  present  In  the  request  or  indication  primitives,  the  local  detail  calling  parameter  shall  not  be  less  than  64; 

however,  it  is  recommesided  that  at  least  512  octets  ba  support^. 


3.1.1.4        Local  detail  Oiled 

The  local  detail  called  parameter  in  the  initiate  response  shall  specify  the  negotiated  max_mms_pdu_sl2e 
for  the  application  association. 

If  the  local  detail  calling  parameter  was  oroitted  in  the  indication  primitive,  then  the  local  detail  called 
parameter: 

a)  may  be  omitted  from  the  response,  indicating  that  the  calling  MMS  implementation  and  the 
called  MMS  implementation  are  prepared  to  support  an  unbounded  max__mms_pdu_size; 

b)  may  be  specified  in  the  response,  indicating  a  requiremer^t  to  support  the  specified  value  for 
maxmmspdusize. 

If  the  loc^  detail  calling  parameter  was  included  in  the  request,  then  this  parameter  shall  be  present  in  the 
response  and  its  value  shall  be  less  than  or  equal  to  the  value  of  the  local  detail  calling  parameter  of  the 
request. 
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If  present  In  the  response,  the  local  detail  called  parameter  shall  not  be  less  than  64;  however,  it  is 
recommended  that  at  least  512  octets  t>e  supported. 


8.2      VMD  support 


8.3      Domain  management 


8.3.1       List  of  capabilities 

Only  one  capability  shall  be  described  in  each  Visible  String  of  the  SEQUENCE  OF. 


8.3.2       Initiate  Download  Sequence  service 

The  Ust  of  Capability  parameter  shall  follow  the  limitations  of  8.3.1. 

The  syntax  and  semantics  of  the  capabilities  shall  be  defined  by  the  Server  in  the  PICS.  Any  deviation  from 
the  defined  syntax  and  semantics  shall  be  grounds  for  the  Server  to  return  a  service  error  with  Error  Qass 
=  RESOURCE  and  Error  Code  =  CAPABILITY-UNKNOWN. 


8.3.3       Download  Segment  service 

A  client  that  receives  a  Download  Segment  indication  after  issuing  a  Download  Segment  Result(+)  with  the 
MoreFollows  parameter  equal  to  FALSE  or  after  issuing  a  Download  Segment  Result(-)  shall  issue  either  a 
service  en-or,  specifying  an  Error  Qass  =  SERVICE  and  an  En-or  Code  =  PRIMITIVES-OUT-OF-SEQUENCE, 
or  an  Atx)rt  request. 


8.3.4       Terminate  Download  Sequence  service 

if  a  client  receives  a  Terminate  Download  Sequence  indication  in  which  the  Discard  parameter  is  absent  and 
the  client  has  not  issued  a  Download  Segment  response  with  the  More  Follows  parameter  =  FALSE  for  that 
Domain,  It  shall  behave  as  if  it  had  received  a  Terminate  Download  Sequence  indication  with  the  Discard 
parameter  present  with  en-or  dass  =  VMD-STATE  and  error  code  =  DOMAIN-TRANSFER-PROBLEM.  It  is 
then  up  to  the  client  application  to  determine  the  true  state  of  the  Domain  and  tal<e  any  recovery  action. 


8.3.5       Initiate  Upload  Sequence  service 

The  Ust  of  Capability  parameter  shall  follow  the  limitations  of  8.3.1. 
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8.3.6  Upload  Segment  service 

A  server  that  receives  an  Upload  Segment  indication  for  an  Upioad  State  Maciiine  for  which  it  has  issued 
an  Upload  Segnient  Result(-)  or  an  Upload  Segment  ResiJit(-i-)  with  the  MoreFoliows  parameter  equal  to 
FALSE,  shall  issue  either  a  service  en'or.  specifying  an  Error  Class  =  SERVICE  and  an  Error  Code  = 
PRIMITIVES-OUT-OF-SEQUENCE.  or  an  Abort  request. 

• 

8.3.7  Get  Domain  Attributes  service 

The  Ust  of  Capal^ility  parameter  shall  follow  the  limitations  of  8.3.1. 

8.3.8  Get  Capability  Ust  service 

The  Ust  of  Capability  parameter  shall  follow  the  limitations  of  8.3.1. 

8.4      Program  Invocation  management 

8.4.1  start  service 

A  ProgramlnvocationState  of  non-existent  shall  be  retumed  in  a  Result(-)  when  a  request  to  Start  a  non- 
existent Program  Invocation  Is  received. 

8.4.2  Stop  service 

A  ProgramlnvocationState  of  non-existent  shall  t>e  retumed  in  a  Result(-)  when  a  request  to  Stop  a  non- 
existent Program  Invocation  is  received. 


8.4.3       Resume  service 

A  ProgramlnvocationState  of  non-existent  shall  be  returned  in  a  Result(-)  when  a  request  to  Resume  a  non- 
existent Program  Invocation  Is  received. 


8.4.4       Reset  service 

A  ProgramlnvocationState  of  non-existent  shall  be  retumed  in  a  Result(-)  when  a  request  to  Reset  a  non- 
existent Program  Invocation  is  received. 
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8.5.1  Scattered  access 

It  is  strongly  recommended  that  for  services  which  use  variable  access,  a  Variable  List  Name  or  List  of 
Variable  be  used  Instead  of  Scattered  Access. 

No  implementations  shall  be  required  to  propose  or  accept  the  VSCA  Parameter  CBB. 

8.5.2  Floating  point 

it  is  strongly  recommended  for  sen^ices  which  use  floating  point  types  or  values,  that  ttie  choice  of  floating- 
point in  the  Data  and  TypeSpecification  productions  be  used  instead  of  the  real  choice. 

No  implementations  shall  be  required  to  propose  or  accept  the  REAL  parameter  CBB. 

8.6  Semaphore  management 

Semaphore  services  are  not  considered  in  Phase  1 . 

8.7  Operator  communication 

No  Operator  Communication  agreements  have  been  identified  to  date. 

8.8  Event  management 

Event  Management  services  are  not  considered  in  Phase  1 . 

8.9  Journal  management 

Journal  Management  sen/ices  are  not  considered  in  Phase  1. 
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Annex  A  (normative)  

Backwards  compatibility  agreements 


A.1  Introduction 

There  is  an  installed  iDase  of  real  DiS  9506  based  Implementations.  Providing  support  for  application 
connectivity  to  both  DiS  and  IS  Is  desired  as  a  migration  strategy.  These  implementation  agreements  will 
allow  IS  based  implementations  to  interoperate  with  DIS  based  implementations  as  described  in  ANNEX  B. 
To  achieve  this  backwards  compatibility,  the  IS  implementation  shall  support  ail  of  the  agreements  in  this 
section. 

It  was  found  that  the  Abstract  Syntax  name  object  identifiers  of  both  DIS  and  IS  were  Identical.  Therefore, 
the  use  of  zero  as  the  version  number  allows  differentiation  t)etween  an  IS  and  a  DiS  based  implementation. 
Since  the  abstract  syntax  name  object  identifier  of  any  companion  standard  is  different  from  that  used  by 
the  DiS  implementations,  DIS  Implementations  cannot  Interoperate  with  IS  based  Implementations  in  a 
companion  standard  context. 

NOTES 

1  The  value  of  zero  is  a  valid  value  for  this  parameter  in  the  DIS  and  not  in  the  IS. 

2  There  are  three  types  of  implementations  when  considering  MMS  backwards  compatibility. 

IMP-1 :  An  implementation  based  on  DiS  9506  as  described  in  Annex  B; 

IMP-2:  An  implementation  based  on  IS  9506  with  no  backwards  compatibility  agreenoents 

applied; 

iMP-3:  An  implementation  based  on  IS  9506  which  includes  the  backwards  compatibility 

agreements  of  this  annex.  Such  an  Implementation  can  dynamically  negotiate  to 
interoperate  with  an  IMP-I,  an  IMP-2.  or  an  IMP-3  Implementation. 

Since  the  value  of  the  minor  version  number  is  zero  for  DiS-based  implementations,  and  is  one  or  greater 
for  implementations  of  iSO/lEC  9506,  this  value  can  be  used  to  differentiate  between  IMP-I  and  IMP-2.  An 
IMP-3  system  can  interoperate  with  either  of  these  systems.  If  an  IMP-3  is  the  Calling  system,  it  will  offer  a 
value  of  one  (or  greater)  for  the  proposed  version  number.  An  IMP-1  system  will  respond  with  a  value  of  the 
negotiated  versk>n  number  of  zero,  using  the  negotiation  procedure  defined  in  ISO/lEC  9506.  The  iMP-3 
system  will  accept  this  response,  if  the  iMP-3  system  Is  the  Called  system  and  hias  received  an  Initiate 
request  with  a  value  of  zero  for  the  proposed  version  number  (from  an  IMP-1  system),  it  will  respond  with 
a  value  of  zero  for  the  negotiated  version  number.  By  following  this  procedure,  an  iMP-3  can  interoperate 
with  an  iMP-2  or  with  another  iMP-3  viewed  as  an  IMP-2.  After  association  context  establishment,  an  iMP-3 
system  shall  behave  as  either  an  IMP-I  or  an  iMP-2  system  as  appropriate  on  that  particular  association. 
The  remainder  of  this  section  describes  additional  agreements  which  change  an  iMP-2  implementation  into 
an  iMP-3  implementation. 
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A.2  Backwards  compatibility  agreements  for  calling  MMS 
'  implementations 

A  calling  MMS  implementation  shall  be  capable  of  receiving  and  supporting  a  negotiatedVerslonNumber 
parameter  in  the  Initiate  Service  confirm  of  zero. 

A  calling  MMS  implementation  which  has  received  a  negotiatedVersionNumtjer  parameter  in  the  initiate 
Service  confirm  of  zero  shall  support  the  modifications  described  in  A.4. 

A  calling  MMS  implementation  shall  be  capable  of  receiving  an  Application  Context  Name  parameter  value 
appropriate  to  an  IMP-1  or  IMP-2  in  the  A-Associate  confirm. 

A  calling  MMS  implementation  which  has  received  a  negotiatedVerslonNumber  of  zero  sfiail  be  capable  of 
receiving  and  supporting  an  Initiate  Response  which  has  t>een  encoded  according  to  the  modifications 
described  in  Appendix  B,  specifically  the  capability  of  receiving  and  supporting  a  negotiatedParameterCBB 
containing  exactly  7  bits. 

if  a  calling  MMS  implementation  receives  an  Initiate  confirm  primitive  with  a  negotiatedVerslonNumber 
parameter  equal  to  zero,  the  calling  MMS  implementation  shall  support  the  VUS  conformance  building  bioci< 
if  the  implementation  claims  support  for  any  service  which  contains  one  or  more  parameters  which  indicate 
the  VUS  CBB  in  Its  service  definition. 

A.3     Backwards    compatibility    agreements    for    called  MMS 
implementations 

A  called  MMS  implementation  shall  be  capable  of  receiving  and  supporting  a  proposedVersionNumt>er 
parameter  in  the  Initiate  Service  indication  of  zero. 

A  called  MMS  implementation  which  has  received  a  proposedVersionNumber  parameter  in  the  initiate 
Service  indication  of  zero  shall  support  the  modifications  in  A.4. 

A  called  MMS  implementation  shall  t>e  capable  of  receiving  an  Application  Context  Name  parameter 
appropriate  to  an  IMP-1  or  IMP-2  in  the  A-Associate  indication. 

A  called  MMS  Implementation  shall  be  capable  of  receiving  and  supporting  an  Initiate  Request  which  has 
been  encoded  according  to  the  modifications  described  in  Appendix  B,  specifically  the  capability  of  receiving 
and  supporting  a  proposedParameterCBB  containing  exactly  7  bits. 

If  a  called  MMS  implementation  receives  an  Initiate  indication  primitive  with  a  proposedVersionNumber 
parameter  equal  to  zero,  the  called  MMS  implementation  shall  support  the  VUS  conformance  building  block 
if  the  implementation  claims  support  for  any  service  which  contains  one  or  more  parameters  which  indicate 
the  VUS  CBB  in  its  service  definition. 
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A.4     General  backwards  compatibility  agreements 


A.4.1      VMD  logical  status 

If  the  current  VMD  State  Is  SUPPORT-SERVICES-ALLOWED  and  the  association  minor  version  numt)er  Is 
zero,  then  the  vnidLogicalStatus  parameter  shall  have  a  value  of  STATE-CHANGES-ALLOWED  in  a  Status 
response  or  in  an  unsollcitedStatus  request. 
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Annex  B  (normative)  

DIS  9506  Modifications  Required  for  Backwards  Compatibility 

B.I  Introduction 

This  annex  is  an  integral  part  of  tliis  part.  It  documents  the  nrKxiifications  to  DIS  9506  required  to  describe 
implementations  for  which  the  agreements  of  this  part  provide  backwards  compatibility.  This  annex  as 
applied  to  DIS  9506  Is  referred  to  as  Version  0. 

B.2  References 

[1]      MMS/1  Manufacturing  Message  Specification  -  ISO  DIS  9506  -  Service  Definition,  December  1987 

[2]      MMS/2  Manufacturing  Message  Specification  -  ISO  DIS  9506  -  Protocol  Specification,  December 
1987 

[3]       NBS  OSI  Implementors  Workshop  Agreements  •  December  1987 

B.3  General 

B.3.1       Implementation  base 

Version  0  Is  based  upon  Reference  [3]  in  B.2  as  It  applies  to  MMS. 
B.3.2       Rules  Of  extensibility 

The  following  sentence  is  appended  to  the  last  paragraph  In  section  8.2.1.1.5.2  Proposed  Parameter  C6B 
and  the  last  paragraph  in  section  8.2.1.2.5.2  Negotiated  Parameter  CBB  of  DIS  9506-1. 

'Any  additional  bits  shall  be  ignored." 

B.4     Modifications  to  the  protocol  definitions 
B.4.1       Page  39,  Section  7.5.2  of  DIS  9506-2 
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CHANGE 

reportEventEnrollaentStatus 

[60] 

IMPLICIT 

ReportEventEncollaentStatus-Request , 

TO 

reportEventEnrollmentStatus 

[60] 

ReportEventEnrollaentStatus-Request, 

B.4.2      Page  49,  Section  7.6.4,  DIS  9506-2 


CHANGE 

Appl icat ionReference 
ap-title 

ap- i  nvoca t  i  on- i  d 
ae-quali£ier 
ae- 1 nvoca t  i on- i  d 

::=  SEQUENCE  { 

ISO-8650-ACSE-l.AP-title  OPTIONAL, 
ISO-86  50-ACSE-l.AP-invocat ion-id  OPTIONAL, 
ISO-8650-ACSE-l.AE-qualifier  OPTIONAL, 
ISO-8650-ACSE-l.AE-invocation-id  OPTIONAL  } 

TO 

Applicat ionReference 
ap-title 

ap- i  n voc  a  t  i  on- i  d 
ae-quali£ier 
ae- i nvoca t i on- i d 

: : =  SEQUENCE  ( 

[0]  OBJECT  IDENTIFIER  OPTIONAL, 
[1]  INTEGER  OPTIONAL, 
[2]  INTEGER  OPTIONAL, 
[3]  INTEGER  OPTIONAL  } 

B.4.3      Page  95,  Section  12.2.1  of  DIS  9506-2 


CHANGE 

Structure  [2]  IMPLICIT  SEQUENCE  OF  SEQUENCE  { 
TO 

structure      [2]  IMPLICIT  SEQUENCE  ( 


B.4.4       Page  96,  Section  12.3.1  of  DIS  9506-2 
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CHANGE 

named  [4]  IMPLICIT  SEQUENCE  { 
TO 

named       [5]  IMPLICIT  SEQUENCE  { 


B.4.5      Page  98,  Section  12.4.2  of  DIS  9506-2 


CHANGE 

generalized-time  [10]  IMPLICIT  GeneralizedTime, 
TO 

generalized-time  [11]  IMPLICIT  General izedTime, 


B.4.6      Page  138,  Section  15.14  of  DIS  9506-2 


CHANGE 

addi t ionalDetai 1 

[9] 

IMPLICIT  EE-Additional-Detail  OPTIONAL 

TO 

addi t ionalDetai 1 

[9] 

EE-Additional-Detail  OPTIONAL 

B.4.7       Page  166,  Section  17.10  of  DIS  9506-2 


CHANGE  the  transfer  syntax  object  identifier  value  from 

{  iso    asnl(l)    basic-encoding(l)  } 
TO 

{  joint-iso-ccitt    asnl(l)    basic-encoding(l)  } 
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B.5.1  Filenames 

Fie  Names  are  specified  in  accordance  with  the  NBS  Implementors'  agreenients  for  FTAM  Reference  [3] 
in  B.2. 


Identify  service 

In  the  identify  sen^ice,  the  vendor,  model  and  revision  fields  may  be  of  any  length,  but  only  the  first  64, 16. 
and  16  octets  respectively  are  treated  as  significanL 


B.5.3      initiate  service 

An  MMS  Oient  will: 

a)  propose  1  or  greater  for  the  value  of  the  Proposed  Max  Serv  Outstanding  Called  parameter  In 
the  Initiate  service  when  initiating  the  application  association  (calling); 

b)  offer  1  or  greater  for  the  value  of  the  Negotiated  Max  Serv  Outstanding  Calling  parameter  In  the 
Initiate  service  wfien  receiving  the  application  association  initiation  (called). 

An  MMS  Server  wHI: 

a)  propose  1  or  greater  for  the  value  of  the  Proposed  Max  Serv  Outstanding  Calling  parameter  in 
the  Initiate  service  when  initiating  the  application  association  (calling); 

b)  offer  1  or  greater  for  the  value  of  the  Negotiated  Max  Sen^  Outstanding  Called  parameter  in  the 
Initiate  service  when  receiving  the  application  association  initiation  (called). 


B.5.3.1        Minimum  segment  size 

MMS  implementations  are  able  to  parse  and  process  512  octets  of  MMSpdu  as  they  are  encoded  In  ASN.1 
basic  encoding  rules. 


B.5.3.2       Maximum  segment  size 

The  Max  Segment  Size  is  defined  as  the  maximum  number  of  octets  in  an  MMSpdu  encoded  using  the 
negotiated  transfer  syntax.  This  size  will  apply  to  all  MMSpdu's  with  the  exception  of  the  initiate-Request 
PDU,  initiate-Response  PDU.  and  the  initiate-Error  PDU.  The  max  segment  size  will  be  negotiated  during 
connection  initiation  using  the  Proposed  Max  Segment  Size  and  Negotiated  Max  Segment  Size  parameters 
of  the  MMS  initiate  service. 
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The  Max  Segment  Size  will  be  applied  as  follows: 

a)  Any  received  MMSpdu  wliich  is  less  than  or  equal  to  the  Max  Segment  Size  wll  be  properiy 
parsed  and  processed: 

b)  An  MMS  implementation  will  not  send  an  MMSpdu  whose  size  exceeds  the  Max  Segment  Size. 
B.5.4      Abstract  syntax  name 

The  ASN.1  object  identifier  value  for  the  abstract  syntax  name  wfli  be  the  same  as  specified  on  page  166. 
section  17.10  of  DIS  9506-2. 

B.5.5      Application  context  name 

The  ASN.1  object  identifier  value  for  the  application  context  name  wHI  be  the  same  as  specified  on  page  166, 
section  17.11  of  DIS  9506-2. 

An  MMS  implementation  ignores  the  Application  Context  Name  in  the  A-Associate  indication  and  the  A- 
Associate  confirm. 

B.5.6      Minor  version  number 

The  Minor  Version  Number  is  zero. 

B.6     Parameter  CBB  subset 

The  following  sut)set  of  MMS  Parameter  CBBs  were  considered  during  preparation  of  this  annex: 

a)  STR1: 

b)  NEST: 

c)  VADR: 

d)  VNAM. 
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B.7     Service  subset 

The  following  subset  of  MMS  services  were  considered  during  preparation  of  tills  annex. 

Table  2  -  MMS  Service  Subset 


Initiate 

Output 

Conclude 

TakeControl 

Cancel 

RelinquisiiControi 

Status 

ReportSemapiioreStatus 

vaeiNameusi 

neportrooioenriapnoreotatus 

iQemny 

neportoenfiapnorecntryoiatus 

unsoiicneaouuus 

v/Feaier  rogrami  nvocaiion 

GetCapabNItyList 

DeieteProgramlnvocation 

InitiateOownioadSequence 

Start 

Download  Segment 

Stop 

TerminateDownload  Sequence 

Resume 

InitiateUploadSequence 

Reset 

UploadSegment 

Kill 

TerminateUploadSequence 

GetPrograminvocationAttributes 

RequestDomainDownioad 

ObtainFlie 

RequestDomainUpload 

GetEventCondltionAttributes 

LoadDomainContent 

ReportEventConditionStatus 

StoreDonuiinContent 

GetAiarmSummary 

DeieteDomain 

ReadJoumal 

GetDomalnAttritxjtes 

WriteJoumal 

Read 

initiaiizeJoumal 

Write 

CreateJoumai 

InformationReport 

DeleteJoumal 

GetVariabieAccessAttributes 

ReportJoumalStatus 

Input 
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shaded. 
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Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Office  Document  Architecture  (ODA) 
Special  Interest  Group  (SIG)  of  the  Open  Systems  Environment  Implementors'  Worl<shop  (OIW). 
Development  of  this  document  application  profile  has  been  done  in  liaison  with  several  organizations.  These 
include  the  DoD  Computer-aided  Acquisition  and  Logistic  Support  (GALS)  Office,  Navy's  David  Taylor 
Research  Center,  and  the  ad-hoc  Tiling  Tasl<  Group. 

This  document  application  profile  is  intended  to  t>e  suitable  for  the  interchange  of  large  format  raster  images 
which  may  be  annotated  with  character,  raster,  or  geometric  revisions. 

This  part  contains  four  annexes: 

a)  annex  A  (normative):  Amendments  and  corrigenda; 

b)  annex  B  (informative):  Recommended  practices: 

c)  annex  C  (informative):  References  to  other  standards  and  registers; 

d)  annex  D  (informative):  Supplementary  information  on  attributes. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  a  new 
part.  Deleted  and  replaced  text  will  be  shown  as  strucl(out.  New  and  replacement  text  will  t^e  shown  as 
shaded. 

This  part  uses  a  convention  of  double  and  single  quotes  that  has  been  established  by  ISO  for  use  in  the 
ODA  base  standard  and  related  document  application  profiles.  The  convention  is  to  use  within  the  text 
double  quotes  to  accentuate  ODA  attribute  names  and  single  quotes  to  accentuate  values  for  those 
attributes. 
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0  Introduction 

This  is  the  definition  of  a  specification  for  an  Open  Document  Architecture  (ODA)  Document  Application 
Profile  (DAP)  named  ODA  Image  DAP.  This  DAP  is  suitable  for  interchanging  documents  in  formatted  form. 
The  documents  contain  primarily  raster  graphics  images  but  may  also  contain  character  and  geometric 
graphics  content  portions. 

There  are  two  DAP  object  identifiers  supporting  this  DAP  with  the  only  difference  being  in  the  encoding  of 
the  data  stream.  One  uses  the  ASN.1  based  ODIF  encoding.  The  other  uses  the  SGML/SDIF  based  ODL 
encoding.  When  this  document  refers  to  this  profile,  it  is  referring  to  this  specification  regardless  of  which 
DAP  identifier  may  be  selected  to  create  the  data  stream. 

The  DAP  is  defined  in  accordance  with  ISO  8613-1  and  CCITT  T.41 1  and  follows  the  standardized  proforma 
and  notation  defined  in  ISO  8613-1  Annex  F.  The  DAP  is  based  on  ODA  as  defined  in  ISO  8613  and  the 
Tiled  Raster  Graphics  Addendum  to  ISO  8613,  Part  7. 


1     Scope  and  field  of  applications 

This  DAP  specifies  an  interchange  format  suitable  for  transfer  of  structured  documents  between  equipment 
designed  for  raster  processing.  The  documents  supported  by  this  DAP  are  based  on  a  paradigm  of  an 
electronic  engineering  drawing  or  illustration.  Such  documents  contain  one  or  more  pages.  Each  page 
consists  of  a  base  image  in  the  form  of  a  bi-tonal  raster  graphics,  character,  or  geometric  graphics  content. 
This  base  image  may  be  further  annotated  with  character,  raster  graphics  or  geometric  graphics  content. 
These  latter  content  portions  serve  to  provide  revision  control  for  the  engineering  drawing  or  illustration. 
There  is  no  restriction  on  the  minimum  size  of  the  base  image. 

This  document  defines  a  DAP  that  allows  large  format  raster  documents  to  be  interchanged  in  a  formatted 
form  in  accordance  with  ISO  8613. 

It  is  assumed  tf^t,  when  negotiation  is  performed  by  the  service  using  this  DAP,  ail  non-basic  values  are 
subject  to  negotiation. 

This  DAP  is  independent  of  the  processes  carried  out  in  an  end  system  to  create,  edit,  or  reproduce  raster 
documents.  It  is  also  independent  of  the  means  to  transfer  the  document  which,  for  example,  may  be  by 
means  of  communication  links  or  exchanged  storage  media. 

The  features  of  a  document  that  can  be  interchanged  using  this  DAP  fall  into  the  following  categories: 

a)  Page  format  features  -  these  concern  how  the  layout  of  each  page  of  a  document  will  appear 
when  reproduced; 

b)  Raster  graphics  layout  and  imaging  features  -  these  concern  how  the  document  content  will 
appear  within  pages  of  the  reproduced  document; 

c)  Raster  graphics  coding  -  these  concern  the  raster  graphics  representations  and  control 
functions  that  mal<e  up  the  document  raster  graphics  content. 
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Normative  references 


The  following  references  are  required  in  order  to  implement  this  DAP: 


2.1 


ISO 


[  1  ]       ISO  861 3-1  : 1 989,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Arctiitecture 
(ODA)  and  Interctiange  Format  -  Part  1:  Introduction  and  General  Principles; 

[2]      ISO  861 3-2 : 1 989,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  2:  Document  Structures; 

[3]       ISO  861 3-4  : 1 989,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  4:  Document  Profile; 

[4]      ISO  861 3-5  : 1 989,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  5:  Open  Document  Interchange  Format, 

[5]       ISO  861 3-6 : 1 989,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  6:  Character  Content  Architecture; 

[6]       ISO  861 3-7 : 1 989,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  7:  Raster  Graphics  Content  Architectures; 

[7]       ISO  861 3-8 : 1 989,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  8:  Geometric  Graphics  Content  Architectures; 

[8]       ISO  861 3-1  : 1 991 ,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  1  .Annex  F  -  A  Document  Application  Profile  Proforma  and 


[9]  ISO  861 3-7 :  (to  be  published) ,  Information  processing  -  Text  and  Office  Systems;  Office  Document 
Architecture  (ODA)  and  Interchange  Format  -  Part  7:  Amendment  -  Tiled  Raster  Graphics  Addendum 
to  ISO  8613,  Part  7; 

[10]  ISO  861 3-7 :  (to  be  published).  Information  processing  -  Text  and  Office  Systems;  Office  Document 
Architecture  (ODA)  and  Interchange  Format  -  Part  7:  Amendment  -  Additional  Bit  Order  Mapping 


[11]     ISO  646  :  1990,  Information  processing  -  ISO  7-bit  coded  character  sets  for  Information 
interchange; 

[12]     ISO  8859-1  :  1983,  Information  processing  -  8-bit  Single-byte  coded  graphic  character  sets  -  Part 
1:  Latin  alphabet  No.  1; 

[13]     ISO  6937-2  : 1 983,  Information  processing  -  Coded  character  sets  for  text  communication  -  Part  2: 


Notation; 


Addendum; 
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Latin  alphabet  and  non-alphabetic  characters; 

[14]     ISO  2022  :  1986,  Information  processing  -  ISO  7-bit  and  8-bit  coded  character  sets  -  Code 
extension  techniques; 

[15]     ISO  7350  :  1984,  Text  communication  -  Registration  of  graphic  character  subrepertoires; 

[16]     ISO  8824  : 1987,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Specification 
of  Abstract  Syntax  Notation  One  (ASN.  1)  ; 

[17]     ISO  8825  : 1987,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Specification 
of  Basic  Encoding  Rules  for  Abstract  Syntax  Notation  One  (ASN.  1)  ; 

[18]     ISO  8879  : 1 986,  Information  processing  -  Text  and  office  systems  -  Standard  Generalized  Markup 
Language  (SGML); 

[19]     ISO  8879  : 1986,  Information  processing  -  Text  and  office  systems  -  Standard  Generalized  Markup 
Language  (SGML),  Amendment  1; 

[20]     ISO  9069  :  1988,  Information  processing  -  SGML  support  facilities  -  SGML  Document  Interchange 
Format  (SDIF). 


2.2  CCITT 

[19]     Recommendation  T.4  :  1988,  Standardization  of  Group  3  Facsimile  Apparatus  for  Document 
Transmission. 

[20]     Recommendation  T.6 : 1 988,  Facsimile  Coding  Schemes  and  Coding  Control  Functions  for  Group 
4  Facsimile  Apparatus. 


3     Definitions  and  terminology 


3.1  Definitions 

The  definitions  given  in  ISO  8613-1  are  applicable  to  this  document. 
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3.2      Constituent  names 

Each  constituent  that  may  be  include  in  a  document  that  confomris  to  this  profile  has  been  given  a  unique 
name  which  serves  to  identify  tliat  constituent  throughout  this  profile. 

The  convention  is  that  full  names  are  used  (i.e.,  no  abbreviations  are  used),  two  or  more  words  in  a  name 
are  concatenated  and  each  word  begins  with  a  capital.  Examples  of  constituent  names  used  In  this  profile 
are  CompositePage,  DocumentLayoutRoot,  and  SpecificBlock. 

In  clause  6,  each  constituent  provided  by  this  profile  is  underlined  once  at  the  point  in  the  text  at  which  the 
purpose  of  that  constituent  is  defined.  This  also  serves  to  identify  all  the  constituents  provided  by  this 
profile. 

The  same  constituent  names  are  also  used  in  the  technical  specification  in  clause  7  so  that  there  is  a 
one-to-one  correspondence  between  the  use  of  these  names  in  clauses  6  and  7. 

Although  the  constituent  names  relate  to  the  purpose  of  the  constituents,  the  semantics  of  constituents  must 
not  be  implied  from  the  actual  names  that  are  used.  Also,  these  names  do  not  appear  in  an  interchanged 
document  but  a  mechanism  for  identifying  constituents  in  an  Interchange  document  is  provided.  Thus  in 
an  application  using  this  profile,  the  constituents  may  be  l<nown  to  the  user  by  different  names. 


4  Relationship  to  other  DAPs 

Functionally,  this  DAP  is  a  functional  superset  of  the  CCITT  Recommendation  T.503,  A  Document  Application 
Profile  for  the  Interchange  of  Group  4  Facsimile  Documents. 

5  Conformance 

In  order  to  conform  to  this  DAP,  a  data  stream  representing  a  document  must  meet  the  requirements 
specified  in  5.1. 

The  requirements  for  implementations  that  originate  and/or  receive  data  streams  conforming  to  this  DAP 
are  specified  in  5.2. 


5.1      Data  stream  conformance 

The  following  requirements  apply  to  the  encoding  of  data  streams  that  conform  to  these  agreements: 

a)  The  data  stream  shall  be  encoded  in  accordance  with  the  ASN.1  encoding  rules  defined  in 
ISO  8825  or  the  SGML  grammar  and  syntax  of  ISO  8879; 

b)  The  data  stream  shall  be  structured  in  accordance  with  the  interchange  format  defined  in 
clause  8; 

c)  The  document  shall  be  structured  In  accordance  with  only  the  formatted  document 
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architecture  class  specified  in  clause  7.  in  addition,  the  document  shall  contain  all  mandatory 
constituents  specified  for  that  class  and  may  optionally  contain  constituents  permitted  for  that 
class  as  specified  in  clause  7; 

d)  Each  constituent  shall  contain  all  those  attributes  specified  as  required  for  that  constituent  in 
this  profile.  Other  attributes  may  be  specified  provided  they  are  permitted  for  that  constituent; 

e)  The  attributes  shall  have  values  within  the  range  of  permissible  values  specified  in  this  profile; 

f)  The  encoded  document  shall  be  structured  in  accordance  with  the  abstract  document 
architecture  defined  in  ISO  8613-2; 

g)  The  encoded  document  shall  be  structured  in  accordance  with  the  characteristics  defined  in 
clause  6  and  shall  contain  only  those  features  defined  in  clause  6. 


5.2      Implementation  conformance 

This  clause  states  the  requirements  for  implementations  claiming  conformance  to  this  DAP. 

A  conforming  receiving  implementation  must  be  capable  of  receiving  either  any  data  streams  conforming 
to  this  profile  structured  in  accordance  with  ODIF  or  any  data  streams  conforming  to  this  profile  structured 
in  accordance  with  ODL  or  both  of  these.  Receiving  usually,  but  not  always,  involves  recognizing  and 
further  processing  the  data  stream  elements. 


6    Characteristics  supported  by  this  DAP 

This  clause  descrit>es  the  characteristics  of  documents  that  can  be  represented  by  data  streams  conforming 
to  this  profile.  This  clause  also  describes  how  these  characteristics  are  represented  in  terms  of  divisional 
components  of  the  data  streams. 


6.1  Overview 

This  DAP  describes  the  features  of  ISO  861 3  that  are  needed  to  support  the  interchange  of  documents 
containing  images.  It  specifies  interchange  formats  for  the  transfer  of  structured  documents  with  simple 
layout  structures. 

This  DAP  describes  documents  that  can  be  interchanged  in  the  formatted  form,  which  facilitates  the 
reproduction  of  a  document  as  intended  by  the  originator. 

The  content  within  the  document  forming  the  original  or  base  image(s)  may  be  formatted  processable  raster 
graphics,  formatted  processable  geometric  graphics,  and/or  formatted  character.  This  is  intended  to 
facilitate  the  reproduction  of  the  document  content  as  intended  by  the  originator  or  allows  the  reformatting 
of  the  document  content. 
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The  content  allowed  within  the  document  to  annotate  revisions  to  the  base  image(s)  tnay  also  be  fomiatted 
processatiie  raster  graphics,  formatted  proce^ble  geometric  graphics,  and/or  formatted  character. 

This  clause  describes  the  layout  features  that  can  be  represented  In  documents  conforming  to  this  DAP. 
The  features  are  descriijed  in  terms  that  are  typical  of  the  user-perceived  capabilities  and  semantics  found 
In  a  raster  document  interchange  environment. 

For  the  purpose  ol  interchange,  a  document  is  represented  as  a  collection  of  constituents,  each  of  which 
is  represented  by  a  set  of  attributes.  The  constituents  that  make  up  a  formatted  document  are  defined 
below  in  this  clause  and  are  illustrated  in  figure  1. 


Docunent  Profile 


Generic  Layout 
Structure  (Optional) 


Presentation  Style 
(Optional) 


Specific  Layout 
Structure 


Content  Portion 
Description 

Figure  1  -  Constituents 

Constituents  defined  as  required  must  occur  in  any  document  that  conforms  to  this  profile.  Constituents 
listed  as  optional  may  or  may  not  be  present  in  the  document,  depending  on  the  requirements  of  th<» 
particular  document. 

The  required  constituents  include: 

a)  a  document  profile; 

b)  layout  object  descriptions  representing  a  specific  layout  structure; 

c)  content  portion  description. 

The  only  optional  constituents  are  presentation  style  and  generic  layout  structure. 
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6.2      Logical  constituents 

Not  applicable. 


6.3      Layout  constituents 

This  clause  describes  the  features  of  the  layout  objects  that  can  be  represented  in  documents  conforming 
to  this  DAP. 


6.3.1       Overview  of  the  layout  characteristics 

The  document  structure  allows  the  document  content  to  be  laid  out  and  presented  in  one  or  more  pages. 
Each  page  in  a  document  may  consist  of  a  single  raster  graphics  content.  This  would  be  the  case  for  an 
original  image  of  an  engineering  drawing,  illustration,  or  other  raster  scanned  image.  Optionally,  each  page 
in  a  document  may  consist  of  an  original  image  which  contains  raster  graphics,  geometric  graphics,  and/or 
character  content,  with  additional  character,  raster  graphics  or  geometric  graphics  content,  representing  a 
set  of  revision  annotations  of  the  original  image. 

A  specific  layout  structure  of  the  document  conforming  to  this  application  profile  consists  of  a  four-level 
hierarchy  consisting  of  a  document  layout  root,  composite  pages,  frames,  artd  blocks.  The  document  can 
consist  of  multiple  composite  pages  where  each  page  represents  a  single  image  including  any  revision 
annotations.  The  composite  pages  consist  of  frames  which  in  tum  contain  blocks  containing  the  content 
associated  with  the  base  image  and  the  revision  annotation. 

Figure  2  is  an  illustration  of  the  features  of  the  document  layout  structure  supported  by  this  DAP. 


Document 
Layout 
Root 


I 


Composite 
Pages ( s ) 


I 


I 


Original 
Image 
Frame 


Revision 
Annotation 
Frame ( s ) 


Specific 
Block(s) 


I 


Specific 
Block 


Figure  2  -  Document  layout  structure 
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A  DocumentLayoutRoot  is  the  top  level  in  a  docunient  layout  structure.  A  DocumentLayoutRoot  consists 
of  a  sequence  of  one  or  more  CompositePage  constituent  constraints. 


6.3.3       Page  characteristics 

Only  one  constituent  constraint  Is  provided  to  present  pages  within  a  document. 

A  document  consists  of  a  sequence  of  one  or  more  composite  pages,  in  a  document's  composite  page, 
two  types  of  frames  are  used  to  position  content  information  on  the  page.  One  frame  type  is  used  to 
position  the  content  representing  the  original  image  on  the  page.  Only  one  frame  of  this  type  is  allowed  per 
page,  but  it  may  contain  any  number  of  raster  graphics,  geometric  graphics,  or  character  content  portions. 
The  secorKi  frame  type  is  used  to  position  a  character,  raster  graphics  or  geometric  graphics  content 
representing  a  revision  annotation  on  the  page.  There  may  be  one  or  more  of  the  frames  containing  a 
revision  annotation. 

A  document  may  consist  of  multiple  pages  of  different  sizes.  Each  page  may  be  either  landscape  or  portrait 
orientation.  Both  orientations  are  permitted  in  the  document. 


6.3.3.1  CompositePage 

A  CompositePaae  is  a  constituent  constraint  which  defines  a  composite-page  that  corresponds  to  the  page 
area  used  for  presenting  the  sequence  of  an  Origlnallmage  frame  and  zero  or  more  RevisionAnnotation 
frames. 


6.3.3.2        Page  dimensions 

A  wide  variety  of  page  dimensions  are  supported  including  large  format  raster  documents.  The  dimensions 
of  the  pages  may  be  specified  as  any  value,  in  BMU  measurement  units,  including  the  larger  sizes  produced 
from  foldout-size  images  and  roll  paper.  These  sizes  apply  to  both  portrait  and  landscape  orientations.  The 
page  sizes  include:  ISO  A0-A5,  ANSI  A-K,  Japanese  legal  and  letter,  foldouts  27.94  cm  (1 1  in.)  X  34.56  cm 
(14  in.)  and  27.94  cm  (11  in.)  X  43.18  cm  (17  in.),  and  27.94  cm  (11  in.)  roll  paper. 

Dimensions  equivalent  to  or  less  than  the  common  assured  reproduction  area  (CARA)  of  ISO  A4  and  North 
American  Letter  (NAL)  in  portrait  or  landscape  orientation  are  basic  values.  Larger  page  sizes  including 
those  produced  from  roll  paper  are  non-basic  and  their  use  must  be  indicated  in  the  document  profile  (See 
table  2). 

The  default  dimensions  are  the  CARA  of  North  American  Letter  (A).  Any  default  page  dimensions  may  be 
specific  in  the  document  profile  subject  to  the  maximum  dimensions  defined  atK>ve  by  using  the  "page 
dimensions"  attribute.  The  "page  position"  attribute  may  be  used  to  specify  the  position  of  the  pel  array 
image  on  the  page.  Although  actual  page  dimensions  may  l^e  used  allowing  for  the  raster  conterrt  to 
completely  fill  a  page  leaving  no  lx)rders,  it  is  advised  that  the  assured  reproduction  area  (ARA)  listed  in 
talsie  1  be  used  wherever  feasible.  See  7.3  of  ISO  8613-2  for  general  rules  for  positioning  pages  on 
presentation  surfaces. 
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6.3.3.3        Nominal  page  sizes 

The  nominal  page  sizes  tliat  may  be  specified  are  listed  In  table  1.  In  addition,  1 1  inch  roll  paper  of  any 
length  is  supported.  These  may  be  specified  in  portrait  or  landscape  orientations.  Ail  values  of  nominal 
page  size  are  non-basic  and  hence  all  values  used  In  a  document  must  be  indicated  in  the  document  profile 
using  the  "medium  type"  attribute  (See  table  2). 

Any  of  the  nominal  page  sizes  defined  in  table  1 ,  subject  to  the  restriction  specified  above,  may  be  specified 
as  the  deteult  value  in  the  document  profile. 

Table  1  also  includes  the  recommended  ARA.  Information  loss  may  occur  when  a  document  is  reproduced 
if  the  dimensions    the  CompositePage  exceed  the  ARA  for  the  specified  nominal  page  size. 


6.3.4  Orlginalimage 

An  Orlginalimage  is  a  constituent  constraint  which  defines  a  lowest  level  frame  us^  for  laying  out  the 
original  image  of  an  engineering  drawing,  illustration  or  other  image.  This  frame  contains  one  or  more 
SpecificBlocks  each  of  which  may  contain  one  of  a  character  content  portion,  a  raster  graphics  content 
portton,  or  a  geometric  graphics  content  portion.  Note  that  there  must  be  exactly  one  Origninallmage  frame 
on  each  page. 

This  type  of  frame  has  a  fixed  position  and  dimensions.  The  position,  if  not  specified,  defaults  to  the  origin 
of  the  page.  The  dimensions,  if  not  specified,  default  to  the  maximum  size  that  can  be  achieved  for  the 
position  within  the  area  of  the  page. 


6.3.5  RevlsionAnnotation 

A  RevlsionAnnotation  is  a  constituent  constraint  which  defines  a  lowest  level  frame  used  for  laying  out  the 
revision  annotation  associated  with  the  original  image.  This  frame  contains  a  single  SpecificBlock  containing 
either  a  character  content  portion,  a  raster  graphics  content  portion  or  a  geometric  graphics  content  portion. 

This  type  of  frame  has  a  fixed  position  and  dimensions.  This  provision  provides  for  the  capability  of 
positioning  of  revision  annotation  anywhere  on  the  page.  Registration  of  revision  annotation  over  a  portion 
of  the  origineil  image,  as  in  revision  artwork,  is  accomplished  using  this  capability. 


6.3.6  SpecificBlock 

A  SpecificBlock  is  a  constituent  constraint  which  defines  a  t>aslc  layout  object  used  to  position  and  image 
the  content  portions  associated  with  either  an  Originallmage  or  RevlsionAnnotation  frame. 

The  position  of  the  t>lock  is  fixed  and  defaults  to  the  origin  of  the  superior  frame.  The  dimensions  default 
to  the  maximum  size  that  can  be  achieved  for  the  position  within  the  area  of  the  superior  frame. 
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6.3.7  GenericBlock 

QenericBlock  is  a  constituent  constraint  wliich  deflnes  a  iayout  ot>ject  class  wliich  can  define  content  tiiat 
is  common  and  can  be  referenced  throughout  the  document.  Any  content  type  (raster,  character,  or 
geometric  graphics)  can  be  defined  using  this  technique. 
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Table  1  Dimensions  for  various  page  sizes 


Pag«typ« 

Size 

Size  (BMU) 

ARA  (BIMU) 

•  Metric 

IS0-A5 

148mm  X  210mm 

7015  x  9920 

not  defined 

IS0-A4 

210mm  X  297mm 

9920  X  14030 

9240  X  13200 

IS0-A3 

297mm  x  420mm 

14030  X  19840 

13200  X  18480 

IS0-A2 

420mm  x  594mm 

19840  x  28060 

18898  x  27118 

IS0-A1 

594mm  x  841mm 

28060  x  39680 

26173  x  37843 

ISO-AO 

841mm  x  1189mm 

39680  x  56120 

37843  X  54283 

•  ANSI.  North  American  (NA) 

NA-A 

8.5in  X  Ilin 

10200  X  13200 

9240  X  12400 

NA-B 

Ilin  X  17in 

13200  x  20400 

12744  X  19656 

NA-C 

17in  X  22in 

20400  x  26400 

19500  x  25800 

NA-D 

22in  X  34in 

26400  x  40800 

25800  x  39600 

NA-E 

34in  X  44in 

40800  x  52800 

39600  x  52200 

NA-F 

28in  X  40in 

33600  x  48000 

32400  X  47400 

NA-G 

Ilin  X  90in 

13200  X 108000 

12400  X  106800 

NA-H 

28in  X  143in 

33600  X 171600 

31400  X  170400 

NA-J 

34in  X  176in 

40800  x  211200 

39600x210000 

NA-K 

40in  X  143in 

48000  X 171600 

47400  X  170400 

NA-Legal 

8.5in  X  14in 

10200  X  16800 

9240  X  15480 

-  Foldouts 

Small 

Ilin  X  14in 

13200  X 16800 

12744  X 15480 

NA-B 

Ilin  X  17in 

13200  x  20400 

12744  X 19656 

-  Japan 

1  Legal 

257mm  x  364mm 

12141  X  17196 

11200X  15300 

1  Letter 

182mm  x  257mm 

8598  X 12141 

7600  X  10200 

Tutorial  Note  -  These  page  sizes  are  for  the  portrait  orientation. 
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Attributes 

Basic  values 

Default 
values 

Non«baslc 
values 

Page  dimensions  ** 

CARA  NA  A. 
ISO  A4 

CARA  NA-A 

ARA  NA  B-K, 
ISO  A0-A3,Japan 
legal. 

ir  Roll  Paper 

Medium-type  ** 
(Nominal  page  size) 

None 

None 

NA  A-K, 
ISO  A0-A5. 
Japan  letter  & 
legal, 

11'  Roll  Paper 

Tutorial  Note  -  See  table  1 


6.4      Document  layout  characteristics 

Tills  DAP  provides  only  for  fornnatted  documents.  Hence,  no  provision  is  made  for  constraining  the 
document  layout  process  other  than  as  implied  in  the  formatted  documents  supported  by  this  DAP.  In 
particular,  these  formatted  documents  are  characterized  by  the  following: 

a)  Documents  containing  only  composite  pages; 

b)  Documents  may  contain  one  or  more  pages; 

c)  Pages  may  vary  by  orientation  within  a  document; 

$       d)  As  a  minimum,  each  page  contains  a  single  raster  graphics,  geometric  graphics,  or  character 
content  portion,  representing  the  original  image; 

e)  Each  page  may  additionally  contain  one  or  more  character,  raster  graphics  or  geometric 
graphics  content  portions  representing  revision  annotation; 

f)  Content  is  positioned  within  fixed  position  and  dimension  frames. 


6.5      Content  layout  and  imaging  control 

A  document  is  modelled  as  an  original  image  with  optional  revision  annotation(s).  The  original  image  and 
the  revision  annotation  (s)  may  be  represented  by  either  character,  raster  graphics,  or  geometric  graphics 
content  portions,  as  specified  in  ISO  8613-6,  ISO  8613-7  and  ISO  8613-8,  respectively. 

The  content  architectures  that  may  be  specified  using  the  attribute  "content  architecture  class"  are  formatted 
character,  formatted  processable  raster  graphics  and  formatted  processable  geometric  graphics.  Any  of 
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the  above  contents  may  be  specified  as  tlie  defauit  in  tiie  document  profile. 


6.5.1 


Raster  graphics  content 


6.5.1.1 


Introduction 


This  clause  defines  the  features  that  are  applicable  to  the  raster  graphics  content. 
The  default  values  for  the  following  features  may  be  specified  in  the  document  profile: 

a)  type  of  coding  (required); 

b)  compression; 

c)  pel  path; 

d)  line  progression; 

e)  pel  spacing; 

f)  spacing  ratio. 

The  specification  in  a  document  of  a  non-basic  value  by  a  presentation  or  coding  attribute  must  be  indicated 
In  the  document  profile. 


6.5.1.2        Raster  graphics  content  architecture 

The  formatted  processable  raster  graphics  content  architecture  is  supported  by  this  DAP  and  will  frequently 
be  the  primary  content  architecture  in  a  document. 

In  a  composite  page,  multiple  content  portions  may  be  associated  with  the  original  image,  whereas  only  one 
content  portion  may  be  associated  with  a  given  revision  annotation. 


6.5.1.3        Raster  graphics  encoding  methods 

The  content  may  be  encoded  in  accordance  with  the  encoding  schemes  defined  in  CCITT 
Recommendations  T.4  and  T.6.  In  the  case  of  T.4,  either  the  one-dimensional  or  two  dimensional  encoding 
scheme  may  be  used.  Also  the  'bit-map  encoding'  scheme  defined  in  ISO  8613-7  may  b>€  used.  All  these 
forms  of  encoding  may  t>e  used  in  a  single  document  and  all  are  basic  values.  'Uncompressed'  mode  of 
encoding  may  also  be  used  but  only  as  a  non-basic  value. 

In  a  content  portion,  it  is  required  that  the  coding  attribute  ''numt)er  of  pels  per  line"  is  specified.  The  coding 
attribute  "number  of  lines"  may  also  be  specified.  No  restriction  is  placed  on  the  values  that  may  be 
specified  for  these  coding  attributes.  This  profile  places  no  constraints  on  the  size  of  the  pel  arrays  that  may 
be  used. 
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The  type  of  coding  method  used  is  specified  by  the  attribute  type  of  coding".  The  use  of  this  attribute  is 
mandatory  in  the  'document  architecture  defauits'  of  the  document  profile  to  define  the  default  value  of 
either  T.6  encoding'  (untiled),  T.6  encoding  -  MSB'  (untiled),  or  'tiled  encoding'.  The  use  of  this  attribute 
in  the  description  of  the  content  portions  is  non-mandatory.  If  this  attribute  is  not  specified  for  a  particular 
content  portion,  then  the  default  value  specified  in  the  "document  architecture  defaults"  of  the  document 
profile  is  used. 

If  the  tiled  encoding  method  is  used,  the  default  value  of  512  for  the  "number  of  pels  per  tile  line"  and 
'numt}er  of  lines  per  tile"  must  be  used.  No  other  values  are  supported,  therefore  these  two  attributes  do 
not  need  to  be  specified.  If  the  "tile  types"  attribute  is  not  present,  then  all  tiles  will  be  T.6  encoded.  If  It  is 
present,  then  there  must  be  a  value  specified  for  each  tile  in  which  case  only  'null  background*,  'null 
foreground',  'T.6  encoded',  'T.6  encoded  -  MSB',  or  'bitmap  encoded'  values  are  supported.  The  T.4 
encodings  are  nc^  supported.  There  are  no  restrictions  on  the  use  of  the  liling  offset"  attribute  other  than 
that  specified  in  ISO  8613-7  Addendum. 

See  tabie  D.I,  Annex  D,  for  a  tabulated  list  of  the  attributes  and  their  basic,  default,  and  non-basic  values. 


6.5.1.4        Raster  presentation 

Raster  presentation  is  controlled  by  the  presentation  attributes  specified  in  ISO  8613-7.  This  DAP  provides 
for  additional  constraints  on  these  presentation  attributes  as  specified  below. 

The  basic  values  for  the  attribute  "pel  path"  supported  by  this  profile  are  0  and  90  degrees.  The  "pel  path" 
values  of  180  and  270  degrees  are  non-basic. 

The  t>asic  values  for  the  attribute  "line  progression"  supported  by  this  profile  is  270  degrees.  The  "line 
progression"  value  of  90  degrees  is  non-basic. 

Any  value  may  be  explicitly  specified  for  pel  spacing  provided  that  the  spacing  between  pels  is  not  less  than 
1  BMU.  The  pel  spacing  need  not  be  an  integer  value.  The  value  of  'null'  may  not  be  specified  because 
the  scalable  layout  process  is  not  supported.  The  specification  of  the  spacings  of  16,  12,  8,  6,  5.  4,  3,  2, 
and  1  BMU  between  adjacent  pels  are  basic.  The  specification  of  any  other  spacing  is  non-basic  and  must 
be  specified  in  the  document  profile. 

NOTES 

1  The  basic  pel  spacing  values  listed  above  are  equivalent  to  resolutions  of  75, 100, 150.  200,  240,  300. 400, 
600,  and  1200  pels  per  25.4mm  respectively  when  the  BMU  is  interpreted  as  1  /1 200  inch. 

2  The  attribute  'pel  spacing'  specifies  two  integers,  the  ratio  of  which  determines  the  pel  spacing.  No 
restriction  is  placed  on  the  values  of  these  integers. 

There  are  no  restrictions  on  the  use  of  the  "clipping"  attribute.  The  "image  dimensions"  attribute  is  not 
supported. 

There  are  no  restrictions  placed  on  the  value  of  the  "spacing  ratio"  attribute  providing  that  the  resultant  line 
spacing  is  not  less  than  1  BMU.  Also,  the  line  spacing  need  not  be  an  integral  numl^er  of  BMUs.  All  values 
are  basic. 
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See  table  D.2,  Annex  D,  for  a  tabulated  list  of  the  attributes  and  their  basic,  default,  and  non-basic  values. 


6.5.2       Character  content 

The  formatted  character  content  is  permitted  in  this  DAP  for  use  in  either  the  original  innage  or  in  revision 
annotations  of  that  original  image. 

The  specification  in  a  document  of  a  non-basic  feature  by  a  presentation  attribute  or  control  function  must 
be  indicated  In  the  document  profile. 


6.5.2.1        Character  content  architecture  class 

When  using  character  content,  only  one  content  portion  niay  be  associated  with  a  basic  component.  The 
content  information  in  a  content  F>ortion  must  be  present. 


6.5.2.2        Character  repertoires 

The  basic  character  set  supported  by  this  profile  is  the  primary  character  set  of  ISO  8859-1.  This  must  be 
designated  to  the  GO  set  and  invoi<ed  to  the  GL  Any  other  graphic  character  set  which  is  registered  in 
accordance  with  ISO  2375  may  be  designated  and  invoked  at  any  point  in  the  document  provided  its  use 
is  announced  in  the  document  profile  as  a  non-basic  value  using  the  character  presentation  attribute 
"graphic  character  sets".  No  locking  shift  functions  are  specified  in  this  presentation  attribute.  The  default 
graphic  character  sets  which  apply  to  the  content  portions  within  a  document  can  be  specified  in  the 
document  profUe  using  the  presentation  attribute  "graphic  character  sets". 

Using  code  extension  techniques,  the  graphic  character  sets  designated  and/or  invoked  at  the  beginning 
of  a  content  portion  containing  character  content  are  specified  using  the  presentation  attribute  "graphics 
character  sets". 

If  the  character  set  defined  in  ISO  6937-2  is  designated  and  invoked,  then  the  use  of  any  sub-repertoire 
registered  according  to  ISO  7350  may  be  specified.  All  sub-repertoires  are  non-basic  and  their  use  must 
be  indicated  in  the  document  profile. 


6.5.2.3        Code  extension  techniques 

The  code  extension  techniques  specified  in  ISO  2022  may  be  used  subject  to  the  following  restrictions: 

a)  GO  set:  only  the  primary  character  sets  of  ISO  6937-2,  ISO  8859-X  (where  ISO  8859-X 
corresponds  to  any  finalized  part  of  ISO  8859)  and  a  version  of  ISO  646  may  be  designated  for 
this  set;  these  character  sets  may  only  be  invoked  in  QL; 

b)  G1,  G2.  G3  sets:  no  restrictions  are  placed  on  the  character  sets  that  may  be  designated  for 
these  sets;  these  sets  may  only  be  Invoked  in  GR; 

c)  The  locking  and  single  shift  functions  allowed  should  be  restricted  to  the  following: 
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LS1R  for  the  Gl  set 
LS2R  for  the  G2  set 
,        LS3R  for  the  G3  set 
SS2 
SS3; 

d)  When  specifying  the  presentation  attribute  "graphic  character  sets",  it  is  necessary  to  invoke 
character  sets  for  both  GL  and  GR.  Thus  an  allowed  character  set  must  be  designated  into  GO. 
as  specified  above,  and  invol<ed  into  GR.  It  is  also  necessary  to  invoke  a  cliaracter  set  into  GR 
which  has  been  designated  into  Gl,  G2  or  G3  sets; 

e)  The  empty  set  should  be  designated  and  invoked  in  GR  if  no  other  specific  set  is  invoked 
into  GR. 

The  announcement  and  encoding  of  these  functions  are  to  be  as  specified  in  ISO  2022. 


6.5.2.4        Une  spacing 

Any  value  of  line  spacing  may  be  specified.  Values  of  150,  200,  300  and  400  BMUs  are  basic;  the  use  of 
any  other  value  in  a  document  is  non-basic  and  must  be  indicated  in  the  document  profile.  The  line  spacing 
may  be  specified  at  the  beginning  of  the  content  associated  with  a  basic  component  using  the  presentation 
attribute  "line  spacing".  The  value  may  be  changed  anywhere  within  the  content  portion  using  the  control 
functions  SVS  and  SLS. 


6.5.2.5        Character  spacing 

Any  value  of  character  spacing  may  be  specified.  Values  greater  than  or  equal  to  100  are  basic;  the  use 
of  any  other  value  in  a  document  is  non-basic  and  must  be  indicated  in  the  document  profile.  The  character 
spacing  may  be  specified  at  the  beginning  of  the  content  associated  with  a  b>asic  component  using  the 
attribute  "character  spacing".  The  value  may  be  changed  anywhere  within  a  content  portion  using  the 
control  functions  SHS  or  SCS. 


6.5.2.6        Character  path  and  line  progression 

Both  horizontal  and  vertical  writing  directions  may  be  used  within  a  character  content.  In  the  case  of 
horizontal  writing,  the  characters  progress  either  from  left  to  right  or  from  right  to  left  across  the  page  and 
the  line  progression  is  from  the  top  of  the  page  to  the  bottom.  In  the  case  of  vertical  writing,  the  characters 
progress  from  the  top  of  the  page  to  the  bottom  and  the  line  progression  is  from  the  right  to  the  left.  The 
values  of  character  path  and  line  progression  may  t>e  specified  at  the  beginning  of  the  content  associated 
with  a  basic  component  using  the  presentation  attributes  "character  path"  and  "line  progression", 
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respectively.  These  values  cannot  be  changed  within  a  content  portion. 


6.5.2.7        Character  orientation 

The  character  orientation  may  be  specified  as  0  or  90  degrees  deperxJing  on  whether  vertical  or  liorizontal 
writing  is  used.  When  vertical  writing  is  used,  characters  are  normally  orientated  at  0  degrees.  When 
horizontal  writing  is  used,  characters  may  be  orientated  at  0  or  90  degrees.  A  value  of  0  degrees  is  t)asic; 
a  value  of  90  degrees  is  non-basic  and  its  use  in  a  document  must  be  indicated  in  the  document  profile. 
The  value  df  the  character  orientation  is  specified  at  the  beginning  of  the  content  associated  with  a  basic 
component  by  the  presentation  attribute  'character  orientation*.  This  value  cannot  be  changed  within  the 
content. 


6.5.2.8  Emphasis 

The  following  modes  of  emphasising  graphic  characters  may  be  distinguished: 


a) 

normal  rendition; 

b) 

normal  intensity; 

c) 

increased  intensity  (bold); 

d) 

italicised; 

e) 

not  italicised; 

f) 

underlined; 

g) 

doubly  underlined; 

h) 

not  underlined; 

1) 

crossed-out; 

J) 

not  crossed-out. 

All  the  above  modes  of  emphasis  are  basic,  if  no  default  mode  is  explicitly  specified  in  the  document  profHe, 
then  the  default  mode  is  normal  rendition.  The  mode  of  emphasis  may  be  specified  at  the  t)eginning  of  the 
content  associated  with  a  basic  component  using  the  presentation  attribute  'graphic  rendition'.  The  mode 
may  t>e  changed  anywhere  within  the  content  using  the  control  function  SGR.  The  mode  of  emphasis 
remains  in  effect  within  the  content  associated  with  a  basic  component  until  changed  into  a  mutually 
exclusive  mode  or  by  the  specification  of  'normal  rendition'.  Mutually  exclusive  modes  are  normal/increased 
intensity,  italicized/not  italicized,  underlined/not  underlined  and  crossed  out/not  crossed-out.  One  mode 
from  each  mutually  exclusive  set  may  be  in  operation  at  any  point  in  the  document  content.  Nomnal 
rendition  cancels  the  effect  of  all  methods  of  emphasis  that  are  currently  in  operation  and  specifies  that  the 
text  should  be  displayed  in  accordance  with  the  default  rendition  parameters  set  for  the  presentation  device. 
Thus,  for  example,  if  it  is  required  to  ensure  that  the  content  is  not  underlined,  then  it  is  necessary  to 
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explicitly  specify  tiiat  underlined  is  not  to  be  used. 


6.5.2.9  Tabulation 

TatMJIation  stop  positions  may  be  specified  at  any  character  position  along  the  character  path.  Each  stop 
is  specified  by  means  of  the  following: 

a)  The  tabulation  position  relative  to  the  margin  position  in  the  direction  opposite  to  the 
character  path; 

b)  An  alignment  qualifier  thiat  specifies  the  type  of  alignment  to  be  used  at  the  designated 
tabulation  position.  The  type  may  be  specified  as  one  of  the  following: 

start  aligned; 

end  aligned; 

centered; 

aligned  around. 

These  alignment  qualifiers  are  defined  in  ISO  8613-6.  If  the  alignment  qualifier  is  not  explicitly  specified,  then 
it  is  assumed  that  start  aligned  is  to  l^e  used.  Only  one  set  of  tabulation  stops  can  be  specified  to  be 
applicable  to  the  content  associated  with  a  Isasic  component.  No  limit  is  placed  on  the  numt)er  of  tabulation 
stops  that  can  be  specified  within  a  given  set.  The  set  of  tabulation  stop  positions  associated  with  the 
content  of  a  basic  component  are  specified  using  the  presentation  attribute  "line  layout  table".  Tatxjiation 
stop  positions  are  invoi<ed  within  the  content  using  the  control  function  STAB. 


6.5.2.10  Alignment 

This  feature  is  concerned  with  how  the  first  and  last  characters  on  each  line  of  character  content  is  to  be 
laid  out  during  the  formatting  process.  The  following  values  of  alignment  may  t>e  specified: 

a)  start  aligned; 

b)  end  aligned; 

c)  centred; 

d)  justified. 

The  semantics  of  these  values  are  as  defined  in  ISO  8613-6.  The  presentation  attribute  "alignment"  is  used 
to  specify  the  alignment  that  is  applical^le  to  the  content  associated  with  a  t>asic  component.  The  alignment 
value  cannot  be  changed  within  a  content  portion. 
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Any  number  of  fonts  may  used  within  a  document.  Tlie  fonts  used  in  a  particular  document  are  specified 
in  the  document  profile  using  tiie  attribute  "font  lisf .  Furtlier  information  coriceming  the  specification  of  font 
references  in  the  document  profile  is  given  in  Annex  B.  The  fonts  that  may  be  used  within  the  content 
associated  with  each  basic  component  are  specified  by  the  presentation  attribute  "character  fonts'.  Up  to 
10  fonts  tal<en  from  the  list  specified  by  the  attribute  font  list"  may  be  specified  by  the  attribute  "character 
fonts".  The  font  to  be  used  at  the  start  of  the  content  associated  with  a  basic  component  is  specified  using 
the  attribute  "graphic  rendition".  The  fonts  used  within  the  content  may  be  changed  using  the  control 
function  SGR. 


6.5.2.12       Reverse  character  strings 

Bi-directional  writing  is  supported  by  this  profile.  IHence.  a  string  of  characters  in  a  content  portion 
associated  with  a  basic  component  may  be  specified  to  be  imaged  in  the  reverse  direction  of  the 
immediately  preceding  character  string.  Such  strings  can  be  specified  by  the  control  function  SAS  as 
defined  in  ISO  8613-6.  This  control  function  is  provided  for  cases  in  which  the  text  belongs  to  different 
languages  and  the  character  content  is  written,  for  example,  from  left  to  right  or  from  right  to  left  within  the 
same  line  of  ciiaracters,  dependent  upon  the  language  and/or  character  set  Iseing  used. 

NOTE  -  The  use  of  this  control  function  cannot  be  indicated  in  the  document  profile.  Thus  it  is  intended  that 
implementations  should  ignore  this  control  function  when  reverse  character  string  layout  and  presentation  is 
not  supported. 


6.5.2.13       Superscripts  and  subscripts 

Superscripts  and  subscripts  may  be  specified  anywhere  within  the  content  associated  with  a  basic 
component  by  using  the  control  functions  'PLU'  and  'Pl-D'.  The  use  of  these  control  functions  sliail  be  in 
accordance  with  ISO  8613-6. 


6.5.2.14      Substitution  of  characters 

The  control  function  'SUB'  is  provided  to  represent  characters  produced  by  a  local  system  that  cannot  be 
represented  by  a  character  within  a  character  set  supported  by  this  profile. 


6.5.2.15       Use  of  control  functions 

The  following  is  a  list  of  all  the  control  functions  and  parameter  values  (where  applicable)  that  may  be 
specified  in  character  content: 

a)  SHS  -  set  horizontal  spacing; 

b)  SOS  -  set  ciiaracter  spacing; 

c)  SVS  -  set  vertical  spacing; 
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d)  SLS  -  set  line  spacing; 

e)  SGR  -  set  graphic  rendition; 

f)  STAB  -  selective  tabulation  (allowed  parameter  values:  any); 

g)  SRS  -  start  reverse  string  (allowed  paranfieters:  any); 

h)  PLD  -  partial  line  down; 

i)  PLU  -  partial  line  up; 

j)  SUB  -  substitute  character; 
k)  SP  -  space; 
I)  CR  -  carriage  return; 
m)  LF  -  line  feed; 

n)     -  code  extension  control  functions  . 
6.5.3       Geometric  graphics  content 

The  formatted  processat)le  graphics  content  is  permitted  in  this  DAP  for  use  in  either  the  original  image  or 
in  the  revision  annotation  of  that  image.  Such  geometric  graphics  content  is  encoded  as  CGM  (Computer 
Graphics  Metafile)  metafiles  in  accordance  with  ISO  8632  and  ISO  8613-8.  Each  CGM  figure  must  consist 
of  a  single  picture  only. 

Further  information  concerning  the  specification  of  geometric  graphics  content  infomnation  is  given  in  Annex 
B. 

6.6      Miscellaneous  features 
6.6.1       Resource  documents 

A  GenericBlock  may  refer  to  a  corresponding  constituent  in  a  resource  document.  The  GenericBlock  in  the 
resource  document  may  refer  to  content  portions  and  to  presentation  styles  that  are  contained  within  the 
resource  document.  These  are  the  only  constituents  that  may  appear  in  a  resource  document. 
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6.6^      Application  comments 

Specification  of  tlie  attribute  "application  comments'  Is  optional.  When  used  In  conjunction  with  the  type 
of  coding'  of  tHed  encoding*,  it  contains  a  sequence  of  positive  integers,  one  for  each  tile  in  the  content 
portion.  The  sequence  of  Integers  Is  a  set  of  indices  representing  the  octet  offsets  to  the  beginning  of  the 
respective  ties,  starting  from  the  beginning  of  tlie  'content  information'.  A  tHe  Index  of  zero(0)  indicates  tfiat 
the  respective  tHe  Is  null.  The  integers  will  be  sequenced  in  the  same  order  as  the  tiles.  The  ties  will  be 
sequericed  primarily  in  the  pel  path  and  secondarily  in  the  line  progression  direction  as  defined  by  the 
presentation  attributes. 

6.7      Document  management  features 

Every  document  interchanged  in  accordance  with  this  DAP  must  include  a  document  profile  containing 
information  which  relates  to  the  document  as  a  whole. 

The  features  specified  by  the  document  profile  are  listed  t>elow.  A  definition  of  the  information  contained 
in  these  features  is  given  in  the  corresponding  attribute  definitions  In  ISO  8613-4. 

Document  constituent  information: 

a)  specific  layout  structure; 

b)  generic  layout  structure; 

c)  presentation  styles  (optional); 

d)  resource  document  information  (optional). 
Document  characteristics: 

a)  document  application  profile; 

b)  document  application  profile  defaults; 

c)  document  architecture  class; 

d)  content  architecture  class; 

e)  interchange  format  class; 

f)  ODA  version  date; 

g)  raster  graphics  content  defaults. 
Non-basic  document  characteristics: 

a)  page  dimensions; 
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b) 


medium  type; 


c) 


raster  graphics  presentation  features. 


Document 


management  attributes: 


a) 


document  description  (see  note  1); 


b)  dates  and  times; 

c)  originators; 

d)  other  user  information; 

e)  external  references; 

f)  local  file  references; 

g)  content  attributes; 

h)  security  information. 

NOTE  -  The  document  description  includes  the  specification  of  the  document  reference. 
The  attributes  applicable  to  the  document  profile  are  defined  in  table  D.3,  Annex  D. 

7    Specification  of  constituent  constraints 
7.1      Document  profile  constraints 

7.1.1       Macro  definitions 

-  General  macros  -- 
DEFINE(FDA.  "{'fomiatted'}") 

DEFINE(DAC.'DocumentProfile  (Document-architecture-class)") 

DEFINE(FC."  ASN.1{282  60}")  -  Character  formatted - 

DEFINE(FPR,"  ASN.1  {2827  2}")  ~  Raster  graphics  fonnatted  processable  ~ 
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DEFINECFPG,"  ASN.1  {2828  0}")  ~  Geometric  graphics  formatted  processable  - 

~  Basic  page  dimensions.  ~ 
DEFINE(BasicPageDimension,'' 

REQ  #horizontai<limension  {REQ  #fixed-dimenslon  {  1..9240  }}. 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {  1.. 12400  }} 
I  REQ  #horizontai-dimension  {REQ  #fixed-dlmenslon  {  1.. 12400  }}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {  1..9240  }} 
") 

~  Any  size  equal  to  or  smaller  than  CARA  (Common  Assured  Reproduction  Area)  of  ISO  A4  and  NA  A.  Both 
Portrait  and  Landscape  nnay  be  specified.  - 

-  Non-basic  page  dimensions.  - 
DEFINE(NonBasicPageDimensions,' 

{REQ  #horizontal-dimension  {REQ  #fixed-dimension  {1.. 39680}}, 

REQ  #vertical-dimension  {REQ  #fixed-dimension  {12401. .56120}}} 

I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {9241. .39^}}, 

REQ  #verticai-dimension  {REQ  #fixed-dimension  {1.. 56120}}} 

-  up  to  ISO  AO  portrait  - 

I  {REQ  #hori2ontal-dimension  {REQ  #fixed-dimension  {1.. 561 20}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {9241. .39680}}} 
I  {REQ  #hori2ontal-dimension  {REQ  #fix«j-dimension  {12401. .561 20}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {1.. 39680}}} 

--  up  to  ISO  AO  landscape  -- 
I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {1.. 48000}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {12401  ..21 1200}}} 
I  {REQ  #hoii2ontal  dimension  {REQ  #fixed-dimension  {9241. .48000}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {1.. 21 1200}}} 

-  up  to  ANSI  J/K  portrait  -- 

I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {1.. 21 1200}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {9241  ..48000}}} 
I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {12401. .21 1200}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {1.. 48000}}} 

--  up  to  ANSI  J/K  landscape  - 
I  {REQ  #horcontal-dimension  {REQ  #fixed-dimension  {1.. 12141}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {12401. .17196}}} 
I  {REQ  #horizontal-dlmension  {REQ  #fixed-dimension  {9241..12141}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {1.. 17196}}} 

-  up  to  Japanese  legal  portrait  - 

I  {REQ  #hori2ontal-dimension  {REQ  #fixed-dimension  {1.. 17196}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {9241..12141}}} 
I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {12401..17196}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {1.. 12141}}} 

-  up  to  Japanese  legal  landscape  - 

I  {REQ  #hori2ontal-dimension  {REQ  #fixed-dimension  {13200}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {>=  16801}}} 
-  Any  portrait  size  larger  than  the  typical  foldout  size  (11  in  x  14  in)  including  11  Inch  roll  paper.  - 
I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {>=  16801}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {13200}}} 
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~  Any  landscape  size  larger  than  the  typical  foldoLit  size  (14  in  x  1 1  in)  including  1 1  inch  roll  paper  - 
") 

DEFINE(PermissiblePageDimensions,'' 

{REQ  #horizontal-dlmension  {REQ  #flxed-dimension  {1.. 39680}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {1.. 56120}}} 

-  up  to  ISO  AO  portrait  - 

I  {REQ  #horizontai-dimenslon  {REQ  #fixed-dimension  {1.. 56120}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {1.. 39680}}} 

~  up  to  ISO  AO  landscape  - 
I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {1.. 48000}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {1..211200}}} 

--  up  to  ANSI  J/K  portrait  - 
I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {1.. 21 1200}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {1.. 48000}}} 

-  up  to  ANSI  J/K  landscape  - 

I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {1..12141}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {1.. 17196}}} 

-  up  to  Japanese  legal  portrait  - 

I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {1.. 17196}}, 
REQ  #vertical-dimension  {REQ  #flxed-dimension  {1..12141}}} 

-  up  to  Japanese  legal  landscape  ~ 

") 

DEFINE(NominalPageSizes,'' 

~  ISO  Page  Sizes  - 

REQ  #horizontal-dimension  {7015},  REQ  #vertical-dimension  {9920} 

-  ISO  A5  Portrait  -- 

I  REQ  #horizontal-dimension  {9920},  REQ  #vertical-dimension  {7015} 

ISO  A5  Landscape  - 
I  REQ  #horizontal-dimension  {9920},  REQ  #vertical-dimension  {14030} 

-  ISO  A4  Portrait  - 

I  REQ  #horizontal-dimension  {14030},  REQ  #vertical-dimension  {9920}  . 

-  ISO  A4  Landscape  -- 

I  REQ  #horizontal-dimension  {14030},  REQ  #vertical-dimension  {19840} 

-  ISO  A3  Portrait  ~ 

I  REQ  #horizontal-dimension  {19840},  REQ  #vertical-dimension  {14030} 

~  ISO  A3  Landscape  -- 
I  REQ  #horizontal-dimension  {19840},  REQ  #vertical-dimension  {28060} 

--  ISO  A2  Portrait  -- 
I  REQ  #horlzontal-dimension  {28060},  REQ  #vertical-dimension  {19840} 

-  ISO  A2  Landscape  -- 

I  REQ  #horizontal-dimension  {28060},  REQ  #vertical-dimension  {39680} 

-  ISO  A1  Portrait  -- 

I  REQ  #horizontal-dimension  {39680},  REQ  #vertical-dimension  {28060} 

-  ISO  A1  Landscape 

I  REQ  #horizontal-dimension  {39680},  REQ  #vertical-dimension  {56120} 

-  ISO  AO  Portrait  - 
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I  REQ  #horizontal-dimension  {56120},  REQ  #vertical-dimension  {39680} 
~  ISO  AO  Landscape  - 

-  ANSI  Page  Sizes  ~ 

I  REQ  #horizontal-dimenslon  {10200},  REQ  #vertical-dlmension  {13200} 

-  ANSI  A  Portrait - 

I  REQ  #hoi1zontal-dimenslon  {13200},  REQ  #vertlcal-dlmensk)n  {10200} 

-  ANSI  A  Landscape  - 

I  REQ  #horizontal-dlnfienslon  {10200},  REQ  #vertical-dlmension  {16800} 

-  ANSI  Legal  Portrait  - 

I  REQ  #horizontal-dlmenslon  {16800},  REQ  #vertical-dlmenslon  {10200} 

~  ANSI  Legal  Landscape  - 
I  REQ  #horizontal-dimenslon  {13200},  REQ  #vertical-dlmenslon  {20400} 

~  ANSI  B  Portrait  -- 
I  REQ  #horizontal-dimension  {20400},  REQ  #vertical-dimension  {13200} 

--  ANSI  B  I_and3cape  - 
I  REQ  #liorizontai-dimension  {20400},  REQ  #vertical-dimension  {26400} 

-  ANSI  C  Portrait  - 

I  REQ  #liorizontal-dimension  {26400},  REQ  #vertical-dimension  {20400} 

-  ANSI  C  Landscape  - 

I  REQ  #horizontal-dimension  {26400},  REQ  #vertical-dimension  {40800} 

~  ANSI  D  Portrait  ~ 
I  REQ  #horizontal-dimension  {40800},  REQ  #vertical-dimension  {26400} 

-  ANSI  D  Landscape  - 

I  REQ  #horizontal-dimension  {40800},  REQ  #vertical-dimension  {52800} 

~  ANSI  E  Portrait  - 
I  REQ  #horizontal-dimension  {52800},  REQ  #verticai-dimension  {40800} 

-  ANSI  E  Landscape  - 

I  REQ  #horlzontal-dimenslon  {33600},  REQ  #vertical-dimension  {48000} 

~  ANSI  F  Portrait  - 
I  REQ  #horizontal-dimension  {48000},  REQ  #vertical-dimension  {33600} 

-  ANSI  F  Landscape  ~ 

I  REQ  #liorlzontal-dimension  {13200},  REQ  #vertical-dimension  {108000} 

~  ANSI  G  Portrait  - 
I  REQ  #iiorizontal-dimension  {108000},  REQ  #vertical-dimension  {13200} 

-  ANSI  G  Landscape  - 

I  REQ  #horizontal-dimension  {33600},  REQ  #vertical-dimension  {171600} 

-  ANSI  H  Portrait  -- 

I  REQ  #horizontal-dimension  {171600},  REQ  #vertical-dimension  {33600} 

-  ANSI  H  Landscape  -- 

I  REQ  #horizontal-dimension  {40800},  REQ  #vertical-dimension  {211200} 

-  ANSI  J  Portrait  - 

I  REQ  #horizontal-dimension  {211200},  REQ  #vertical-dimension  {40800} 

-  ANSI  J  Landscape  - 

I  REQ  #horizontal-dimension  {48000},  REQ  #vertical-dimension  {171600} 

~  ANSI  K  Portrait  - 
I  REQ  #hori2ontal-dimension  {171600},  REQ  #vertical-dimension  {48000} 

~  ANSI  K  Landscape  ~ 
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-  FokJouts  - 

I  REQ  #horizontal-dimension  {13200},  REQ  #vertlcal-dlmension  {16800} 

--  Foldout  Portrait  -- 
I  REQ  #horizontal-dimension  {16800},  REQ  #vertical-dimension  {13200} 

~  Foldout  LarKJscape  - 
I  REQ  #horizontal-dimenslon  {13200},  REQ  #vertical-dimension  {>=  16801} 

-  Any  portrait  size  larger  than  the  typical  foldout  size  (11  in  x  14  in)  including  1 1  inch  roll  paper  - 
I  REQ  #horizontal-dimension  {>=  16801}.  REQ  #vertical-dimension  {13200} 

-  Any  landscape  size  larger  than  the  typical  foldout  size  (14  In  x  1 1  in)  including  1 1  inch  roll  paper  ~ 


-  Macro  defining  permissible  code  extension  announcers  - 

DEFINE(CDEXTEN,  "  ESC  02/00  05/00.        -  LSO - 
[ESC  02/00  05/03],      -  LSRI  - 
[ESC  02/00  05/05],      -  LSR2 - 
[ESC  02/00  05/07],      --  LSR3  - 
[ESC  02/00  05/10],      --  SS2  - 
[ESC  02/00  05/11]  -SS3~ 


-  Macro  defining  permitted  graphic  renditions  ~ 

DEFINE(GRAPHICRENDITIONS  " 

{'cancel'  |  'increased-intensity' 
I  'italicised'  |  'underlined'  |  'crossed-out' 
i  'primary-font'  |  'first-alternative-font' 
'         I  'second-alternative-font'  |  'third-aiternative-font' 
I  'fourth-aiternative-font'  |  'fifth-alternative-font' 
I  'sixth-alternative-font'  |  'seventh-altemative-font' 
I  'eighth-alternative-font'  |  'ninth-alternative-font' 
1  'dout>ly-underlined'  |  'normal-intensity' 
I  'not-italicised'  |  'not-underlined'  |  'not-crossed-out'},.. 

") 


~  Macros  defining  final  character  for  designation  ~ 

DEFINE(FCORE,  "04/02  -  the  94  characters  of  the  IRV  of  ISO  646 
(revised  1990)  (i.e.,  ASCII)  ~") 

DEFINE(F646.      a  final  character  designating  any  version  of  ISO  646 
except  04/02  ~") 

DEFINE(F94S.      a  final  character  designating  any  registered  94  single 
byte  graphic  character  set  --") 
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DEFINE(F94M.      a  final  character  designating  any  registered  94  muiti 
byte  graphic  character  set 

DEFINE(F96S,      a  final  character  designating  any  registered  96  single 
byte  graphic  character  set 

DEFINE(F96M,      a  final  character  designating  any  registered  96  muiti 
byte  graphic  character  set 

DEFINE(FEMPTY.  "07/14  -  the  empty  set  -") 

~  Macros  defining  designation  sequences  - 

DEFINE(DEG-CORE-GO,  "ESC  02/08  $FCORE") 

-  Designate  the  94  characters  of  the  IRV  of 
ISO  646  to  GO  - 

DEFINE(DEG-646-GO,    "ESC  02/08  $F646") 

~  Designate  any  version  of  ISO  646,  except  04/02, 
to  GO  - 

DEFINE(DEG-ANY-G1 ,   "{ESC  02/09  $F94S 
I  ESC  02/04  02/09  $F94M 
|ESC02/13$F96S 
I  ESC  02/04  02/13  $F96M}") 

-  Designate  any  character  set  to  G1  ~ 

DEFINE(DEG-ANY-G2.    "{ESC  02/10  $F94S 
I  ESC  02/04  02/10  $F94M 
|ESC02/14$F96S 
I  ESC  02/04  02/14  $F96M}") 

-  Designate  any  ciiaracter  set  to  G2  ~ 

DEFINE(DEG-ANY-G3,   "{ESC  02/1 1  $F94S 
I  ESC  02/04  02/11  $F94M 
I  ESC  02/15$F96S 
I  ESC  02/04  02/15  $F96M}") 
~  Designate  any  character  set  to  G3  ~ 

DEFINE(DEG-EMPTY-G1,  "ESC  02/09  $FEMPTY") 

-  Designate  the  empty  set  to  G1  -- 

~  Macros  defining  shift  functions  - 

DEFINE(LSO.    "00/15")        ~  locl<ing  shift  invol<ing  GO  to  GL  - 
DEFINE(LS1R,   "ESC  07/14")    ~  locking  shift  invoking  Gl  to  GR  - 
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DEFINE(LS2R.   "ESC  07/13")    -  locking  shift  Invoking  G2  to  GR  - 
DEFINE(LS3R.   'ESC  07/14")    ~  locking  shift  invoking  G3  to  GR  - 
DEFINE(SS2.    "08/14")       -  single  shift  Invoking  G2  to  GL  - 
DEFiNE(SS3,    "08/15")       ~  single  shift  Invoking  G3  to  GL  - 

--  Macro  defining  pemiissible  graphic  character  sets.  ~ 

DEFINE(PERMIT-GRCHAR.  "  {$DEG-CORE-GO  $LSO 
|$DEG-646-G0  $LSO}, 
{$DEG-ANY-G1  $LS1R 

|$DEG-ANY-G2  $LS2R 

|$DEG-ANY-G3$LS3R}... 
|{$DEG-EMPTY-G1  $LS1R}  ") 

-  Macro  defining  default  graphic  character  sets  - 
DEFINE(DAP-DEFAULT-GRCHAR.  "$PERMIT-GRCHAR") 

-  Macro  defining  basic  character  sets.  Note  that  this  macro  is  defined 

for  clarification  of  the  specification  and  is  not  to  be  used  in  any 
other  part  of  this  DAP  specification.  ~ 

DEFINE(BASIC-GRCHAR.  "  $DEG-CORE-G0  $LSO. 

$DEG-EMPTY-G1  $LS1R  ") 


-  Macro  defining  non-basic  character  sets  ~ 

DEFiNE(NON.BASIC-GRCHAR,  "  {$DEG-646-G0 
|$DEG-ANY-G1 
|$DEG-ANY-G2 
|$DEG-ANY-G3}...  ") 


-  Macro  defining  character  sets  used  in  document  profile  attributes  - 

DEFINE(PROFCHAR. "  {$DEG-CORE-G0  $LSO. 
|$DEG-646-G0$LS0}, 
{$DEG-ANY-G1  $LS1R 
|$DEG-ANY-G2$LS2R 
|$DEG-ANY-G3$LS3R 
|$DEG-EMPTY-G1  $LS1R}  ") 
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-  Macro  defining  comments  cliaracter  sets  ~ 

DEFiNE((X)MCHAR. "  {ESC  02/00  05/00. 

[ESC  02/00  05/03],  -  LSR1 
[ESC  02/00  05/051.  ~  I-SR2 
(ESC  02/00  05/071.  -  LSR3 
[ESC  02/00  05/101.  -  SS2  ■ 
[ESC  02/00  05/111}.  ~SS3 

{$DEG-CORE-G0  [LSOl 
|$DEG-646-G0  [LSOl}. 

{{$DEG-ANY-G1  [$LS1R] 
|$0EG-ANY-G2  [$LS2R] 
|$DEG-ANY-G3  [$LS3R1}... 
|$DEG-EMPTY-G1  $LS1R}}  ") 


-  Macro  defining  ciiaracter  sets  used  for  alternative  representation  - 
DEFINE(ALTCHAR.  "$PROFCHAR") 


7.1.2       Constituent  constraints 


7.1.2.1  DocumentProfile 

{ 

-  Presence  of  document  constituents  - 

REQ     Specific-layout-structure  {'present'}. 

PERM   Generic-layout-structure  {'factor-set'}. 

PERM   Presentation-styles  {'present'}. 

PERM   Resource-document  {ANY_VALUE}, 

PERM   Resources       {MUL  {REQ  #resource-identifier  {ANY  VALUE}. 

REQ  #resource-object-ciass-ldentifier  {ANY  VALUE}}}. 

-  Document  ctiaracteristics  - 

REQ    Document-application-profile  {-  See  clause  8  for  a  definition  of  the  pemnitted  values  for 

tills  attribute.  -}. 

REQ     Document-application-profile-defauits  { 

-  Document  architecture  defaults  ~ 

REQ     #content-architecture-class  {$FPR}, 

PERM   #dimensions  {$PermissibiePageDimensions}, 

PERM   #medium-type  { 


December  1992  (Stable) 


LSO 
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PERM  #nominal-page-size 
PERM  #slde-of-sheet 


{$NominalPageSizes}. 
{ANY  VALUE}}. 


Any  permitted  medium  type.  BotSi  landscape  and  portrait  may  be  specified.  - 


REQ  #type-of-coding 


PERM 
PERM 


PERM 
PERM 


{ASN.1  {28370}- 
I  ASN.1  {28375} 
I  ASN.1  (2  83  76} 
#page-position  {ANYVALUE}, 
raster-grapiiics-contents-defaults  { 


T6  encoding  - 
-  tiled  encoding  ~ 
~  T6  encoding  -  MSB 


}. 


PERM 
PERM 
PERM 


#pel-patii 

#line-progression 

#pel-spacing 


{ANYVALUE}, 
{ANYVALUE}, 
{REQ  #iengtli  {ANY_VALUE}. 
REQ  #pel-spaces  {ANY_VALUE}}. 

PERM  #spacing-ratio 

{REQ  #line-spacing-value  {ANY_VALUE}, 
REQ  #pel-spacing-vaiue  {ANY_VALUE}}, 
PERM   #compression  {ANYVALUE}}, 
#geometric-grapliics-content-defaults  {ANY_VALUE}, 


#clTaracter-content-defau!ts 
PERM  #alignment 
PERM  #cliaracter-spacing 
PERM  #ciTaracter-fonts 
PERM  #ciiaracter-orientation 
PERM  #ciTaracter-path 


{ 


{ANY_VALUE}, 
{ANY_VALUE}, 
{ANY_VALUE}, 
{'0-degrees'  |  '90-degrees'}, 
{'0-degrees'     |  '90-degrees' 
'270-degrees'}, 
PERM  #code-extension-announcers  {$CDEXTEN}, 
PERM  #graphic-ciiaracter-sets  {$PERMIT-GRCHAR}, 
PERM  #grapiiic-character-subrepertoire  {ANY  VALUE}, 
PERM  #graphic-rendition  {$GRAPHiCRENDITIONS}, 
PERM  #iine-progression        {'90-degrees'  |  '270-degrees'}, 
PERM  #iine-spacing  {ANY  VALUE}, 

PERM  #iine-iayout-table         {ANY  VALUE}}, 


'180-degrees' 


-  End  of  document  arciiitecture  defaults  ~ 


REQ  Document-architecture-class 
REQ  Content-architecture-classes 
REQ  Interchange-format-class 


REQ  ODA-version 


{$FDA}. 

{{$FPR  I  $FPG  I  $FC}...}, 

{--  This  attribute  required  only  for  ODIF  interchange.  See 
clause  8  for  a  definition  of  the  permitted  values  for  this 
attribute.  --}, 


{REQ  #standard-or-recommendation    {'ISO  8613'}, 

REQ  #publication-date  {'1991-12-31'}}, 

~  This  date  represents  the  date  that  this  DAP  was  approved.  This  is  the  only 
~  approved  value,  however,  the  date  will  be  changed  if  the  DAP  is  significantly 
-  revised.  If  the  date  is  revised,  use  of  the  new  date  is  required  only  when  the 
~  additional  functionality  is  being  used.  That  is,  legacy  products  may  continue  to 
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-  support  the  earlier  DAP. 
-  Non-basic  document  characteristics  - 


PERM 
PERM 
PERM 
PERM 
PERM 


PERM 


PERM 


Profile-character-sets  {$PROFCHAR}, 

Comments-character-sets  {$COMCHAR}, 

Altemative-representation-character-sets  {$ALTCHAR}. 

Page-dimensions  {MUL  {SNonBasicPageDlmensions}}, 

Medium-types  {MUL{ 

PERM   #nominai-page-slze  {$NomlnalPageSizes}, 

PERM   #side-of-sheet  {ANYVALUE}}}. 

-  All  values  of  "medium  type"  are  non-basic  - 

Coding-attributes  { 

REQ  #raster-graphics-coding-attributes  { 

REQ  #compression  {'uncompressed'}}}. 
Presentation-features  { 
PERM   #character-presentation-features  { 

I  PERM  #character-orientation 

I  PERM  #character-path 

I  PERM  #graphlc-character-sets 


MUL{ 

{'go-degrees'} 

{'90-degrees'.  '180-degrees'.  '270-degrees'} 
{ANY  VALUE}  EXCEPT  {$BASIC-GRCHAR} 


I  PERM  #graphic-character-subrepertoire  {>0} 
I  PERM  #line-spaclng  {ANY_VALUE}  EXCEPT  {150.200.300.400} 

I  PERM  #line-progression  {'90-degrees'}}} 
PERM  #Raster-graphics-presentation-features    {  MUL  { 
I  PERM  #pel-path        {'180-degrees'  | 

'270-degrees'} 
I  PERM         #line-progression  {'90-degrees'} 

I  PERM  #pei-spacing    { REQ  #length{ANY_VALUE}  EXCEPT  {16. 12.8.6.5,4,3.2.1}. 

REQ  #pel-spaces  {ANY  VALUE}  EXCEPT  {1}} 

I  PERM  #spacing-ratio 

{REQ  #llne-spacing-value        {ANY_VALUE}  EXCEPT  {1}. 
REQ  #pel-spacing-value         {ANY_VALUE}  EXCEPT  {1 }}}}}. 

~  End  of  Non-basic  characteristics  ~ 

~  Additional  document  characteristics  ~ 


PERM  Fonts-list 


{MUL 


{REQ  #font-identifier  {ANY_VALUE}, 
REQ  #font-reference  {ANY_VALUE}}}. 
The  format  of  the  parameter  "font-reference"  is  defined  in  annex  B  - 


-  Document  management  attributes  -- 

~  Document  description  ~ 

PERM  Title  {ANY  STRING}, 

PERM  Subject  {ANY  STRING}, 

PERM  Document-type  {ANY  STRING}, 

PERM  Abstract  {ANY  STRING}. 
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PERM  Keywords 

REQ  Document-reference 

-  Dates  and  times  - 
PERM  Document-date-and-time 
PERM  Creation-<late-and-time 
PERM  Local-fHing-date-and-time 
PERM  Expiry-date-and-time 
PERM  Start<iate-and-tlme 
PERM  Purge<late-and-time 
PERM  Release-date-and-time 
PERM  Revision-history 

-Originators  - 
PERM  Organizations 
PERM  Preparers 
PERM  Owners 
PERM  Autliors 

~  Other  user  information  ~ 
PERM  Copyright 
PERM  Status 
PERM  User-specific-codes 
PERM  Distribution-list 
PERM  Additional-information 

~  External  references  ~ 
PERM  References-to-other-documents 
PERM  Superseded-documents 

~  Local  file  references  ~ 
PERM  Locai-file-references 

-  Content  attributes  - 
PERM  Document-size 
PERM  Number-of-pages 
PERM  Languages 

-  Security  information  ~ 
PERM  Authorization 

PERM  Security-classification 
PERM  Access-rights 

} 


{ANYVALUE}. 
{ANY_VALUE}. 


{ANY  STRING}. 
{ANY'STRING}, 
{ANY"STRING}, 
{ANY  STRING}, 
{ANY'STRING}. 
{ANY'STRING}. 
{ANY'STRING}. 
{ANY'VALUE}. 


!  {ANY_STRING}. 
{ANYVALUE}. 
{ANYVALUE}. 
{ANY_VALUE}. 


{ANYVALUE}. 

{ANYSTRING}. 

{ANYSTRING}. 

{ANYVALUE}. 

{ANYVALUE}. 


{ANYVALUE}. 
{ANY_VALUE}. 


{ANYVALUE}, 


{ANYVALUE}. 

{ANYJNTEGER}, 

{ANYSTRING}. 


{ANY  VALUE}. 
{ANY~STRING}, 
{ANY  STRING} 
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7.3     Layout  constituent  constraints 


7.3.1       Macro  definitions 


DERNE(CHAR.'         CONTENT  ID  GFCCharacter-content-portion)") 
DEFINE(RAST,"  CONTENT'~ID'~OF(Raster-graphics-content-portion)') 
DERNE(GEOM.'  CONTENTlD~'OF(Geometric-graphics-content-portion)") 


7.3.2       Factor  constraints 

FACTOR:         ANY-LAYOUT  { 

SPEaFIC: 

PERM  Object-type 

REQ  Object-identifier 

PERM  Subordinates 

PERM  User-visible-name 

PERM  User-readable-comnients 
} 


7.3.3      Constituent  constraints 


7.3.3.1  DocumentLayoutRoot 

DocumentLayoutRoot:  ANY-U\YOUT  { 
SPECIRC: 

REQ    Object-type  { 'document-layout-root'}, 

REQ    Subordinates  {SUBJD_OF(ComposttePage)  + } 

} 

7.3.3.2  CompositePage 

ComposltePage:  ANY-LAYOUT  { 

SPEaRC: 
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REQ  Object-type 

REQ  Subordinates 

PERM  Dimensions 

PERM  Page-position 

PERM  Medium-type 

PERM  imaging-order 

PERM  Application-comments 
} 


{'page'}. 

{SUBJD_OF(Originallmage), 
[SUBJD_OF(RevisionAnnotatlon) + ] }, 
{$PennissiblePageDimensions}, 
{ANY_VALUE}. 

{REQ  #nominal-page-slze  {$NomlnalPageSlzes}, 
REQ  #sida-of-sheet  {ANY  VALUE}}, 
{ANYVALUE}, 
{ANYVALUE} 


7.3.3.3 


Originalimage: 


Originallmage 


ANY-LAYOUT  { 


SPECIFIC: 
REQ  Object-type 
REQ  Subordinates 
PERM  Position 


PERM  Dimensions 


PERM 
} 


Application-comments 


{'frame'}, 

{SUBJD_OF(SpeclflcBlock)  +  }. 
{REQ  #fixed-posltion 

{REQ  #horizontal-positlon  {ANY  VALUE}. 

REQ  #vertlcal-posltion  {ANY  VALUE}}}, 
{REQ  #horizontal-dlmenslon 

{REQ  #flxed-dimenslon{ANY_VALUE}}. 
REQ  #vertlcal-dimension 

{REQ  #flxed-dimenslon{ANY_VALUE}}}. 
{ANYVALUE} 


7.3.3.4  RevisionAnnotatlon 

RevlsionAnnotatton:  ANY-LAYOUT 

SPECIFIC: 
REQ  Object-type 
REQ  Subordinates 
PERM  Position 


PERM  Dimensions 


PERM  Application-comments 


{ 


{'frame'}, 

{SUBJD_OF(SpeclflcBlock) }, 
{REQ  #fixed-posltlon 

{REQ  #horlzontal-posltion  {ANY  VALUE}, 

REQ  #vertlcal-positlon  {ANY  VALUE}}}. 
{REQ  #horizontal-dimenslon 

{REQ  #flxed-dlmenslon{ANY_VALUE}}. 
REQ  #vertlcal-dimension 

{REQ  #fixed-dlmenslon{ANY_VALUE}}}, 
{ANYVALUE}} 
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7.3.3.5 


SpecificBlock 


SpecificBlock:  { 

SPECIFIC: 
REQ  Object-type 
REQ  Object-identifier 
REQ  Content-portions 
PERM  Position 


PERM  Dimensions 


PERM  Object-class 

PERM  Content-architecture-class 

PERM  Transparency 

PERM  Colour 

PERM  User-readable-comments 

PERM  User-visible-name 

PERM  Application-comments 

PERM  Presentation-style 

-  PStylel  for  character 

PERM  Presentation-attributes 


{•block*}. 

{ANYVALUE}, 

{$CHAR  I  $RAST  |  $GEOM}. 

{REQ  #fixed-position  { 

REQ  #horl2ontal-position  {ANY_VALUE}, 

REQ  #vertical-posltion  {ANY_VALUE}}}. 
{REQ  #horizontal-dimension 

{REQ  #fixed-dimension{ANY_VALUE}}, 
REQ  #vertical-dimension 

{ REQ  #f lxed-dimension{ ANY  VALUE } } }, 
{OBJECT_CI_ASS_ID_OF(GenericBlock)}. 
{$FC  I  $FPR  I  $FPG}, 
{'transparent'  |  'opaque'}, 
{'colourless'  |  'white'}, 
{ANYSTRING}, 
{ANYSTRING} 
{ANYVALUE}, 
~  See  8.1.3  and  8.2.3  - 

{STYLEJD_0F(PStyle1) 
STYLEJD_0F(PStyle3}. 
content,  PStyle2  for  geometric,  &  PStyleS  for  raster 

{ 


STYLE  ID  0F(PStyle2) 


CASE  SpecificBlock(Content-portions)  OF  { 


{$CHAR}: 

{PERM 


#chiaracter-attributes 
PERM  #alignment 
PERM  #character-spacing 
PERM  #character-fonts 
PERM  #character-orientatlon 
PERM  #character-path 


{ 


PERM 
PERM 
PERM 
PERM 
PERM 
PERM 
PERM 


{ANYVALUE}, 
{ANYVALUE}, 
{ANYVALUE}, 
{'0-degrees'  |  '90-degrees'}, 
{'0-degrees'     |  '90-degrees' 
'270-degrees'}, 
#code-extenslon-announcers  {$CDEXTEN}, 
#graphic-character-sets  {$PERMIT-GRCHAR}, 
#graphic-character-subrepertoire  {ANY_VALUE}, 


I  '180-degrees' 


}} 


#graphic-rendltlon 
#line-progression 
#line-spacing 
#line-layout-table 


{$GRAPHICRENDITIONS}, 
{'90-degrees'  |  '270-degrees'}, 
{ANYVALUE}. 
{ANYVALUE}. 


{$RAST}: 

{PERM  #raster-graphics-attributes 
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PERM  #Pdl-path 
PERM  #Une-progression 
PERM  #Pel-spaclng 
PERM  #Spacing-ratio 

PERM  #aipping 


{$GEOM}: 

{PERM 


}}} 


{ANY  VALUE}. 
{ANY~VALUE}. 
{ANYVALUE}, 

{REQ  #line-spacing.value  {ANY  VALUE}. 
REQ  #pel-spacing-value  {ANY_VALUE}}. 
{ANYVALUE}}} 


#geometric-graphics-attributes 


PERM  #picture-dimensions 
PERM  #picture-oi1entation 
PERM  #text-rendltion 


{ 

{ANY_VALUE}. 
{ANYVALUE}. 

{PERM  #fonts-list  {ANY_VALUE}, 

PERM  #character-set-lists  {ANY  VALUE}}} 


7.3.3.6 


GenericBlock 


GeneticBlock 


GENERIC: 
REQ  Object-type 
REQ  Content-portions 
PERM  Position 


PERM  Dimensions 


REQ  Object-dass-identifier 

PERM  Resource 

PERM  Content-architecture-ciass 

PERM  Transparency 

PERM  Colour 

PERM  User-readable-comments 

PERM  User-visible-name 

PERM  Application-comments 

PERM  Presentation-style 

-  PStylel  for  cliaracter 

PERM  Presentation-attributes 


{'blocl<'}, 

{$CHAR  I  $RAST  |  $GEOM}. 
{REQ  #fixed-position  { 

REQ  #liori2ontal-positlon  {ANY_VALUE} 

REQ  #vertical-positlon  {ANY_VALUE}}}, 
{REQ  #iiori2ontal-dimension 

{REQ  #flxed-dimension{ANY_VALUE}}. 
REQ  #verticai-dlmension 

{REQ  #fixed-dlmenslon{ANY_VALUE}}}. 

{ANYVALUE}. 
{ANYVALUE}. 
{$FC  I  $FPR  I  $FPG}, 
{'transparent'  |  'opaque'}, 
{'colourless'  |  'wliite'}, 
{ANYSTRING}. 
{ANY-STRING} 
{ANYVALUE}. 
„       8  2  — 

{STYLE  iD_0F(PStyle1) 
STYLE_rD_0F(PStyie3}. 
content.  PStyle2  for  geometric,  &  PStyle3  for  raster 

{ 


STYLE  ID  0F(PStyle2) 


CASE  GenericBlock(Content-portions)  OF  { 

{$CHAR}: 

{PERM  #character-attributes 
PERM  #aiignment 


{ 

{ANY_VALUE}. 
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PERM  #character-spacing  {ANY  VALUE}. 
PERM  #character-fonts  {ANY^VALUE}. 
PERM  #character-orientation  {'0-degrees'  |  '90-degrees'}. 

PERM  #character-path         {'0-degrees'    |     '90-degrees'    |    '180-degrees'  | 

'270-degrees'}, 
PERM  #code-extension-announcer8  {$CDEXTEN}, 
PERM  #graphic-character-sets  {$PERMIT-GRCHAR}, 
PERM  #graphic-character-subrepertolre  {ANY  VALUE}, 
PERM  #graphic-rendition  {$GRAPHICRENDITIONS}. 
PERM  #line-progression        {'90-degrees'  |  '270-degrees'}. 
PERM  #line-spacing  {ANY  VALUE}, 

PERM  #line-layout-table  {ANY_VALUE}. 

» 

{$RAST}: 

{PERM  # raster-graphics-attributes  { 

PERM  #Pel-path  {ANY  VALUE}, 

PERM  #Line-progression  {ANY  VALUE}, 
PERM  #Pel-spacing  {ANY_VALUE}, 

PERM  #Spacing-ratio  {REQ  #line-spacing-value  {ANY_VALUE}, 

REQ  #pel-spacing-value  {ANY_VALUE}} 
PERM  #Clipping  {ANY_VALUE}}} 

{$GEOM}: 

{PERM  #geometric-graphics-attribLites  { 

PERM  #picture-dlmensions  {ANY  VALUE}, 
PERM  #picture-orientation  {ANY  VALUE}, 
PERM  #text-rendition  {PERM  #fonts-list  {ANY  VALUE}, 

PERM  #character-set-lists  {ANY  VALUE}}} 

}}} 


7.4      Layout  style  constraints 

No  layout  style  constraints  applicable  in  this  clause. 


7.5      Presentation  style  constraints 


7.5.1       Macro  definitions 

No  macro  definitions  are  applicable  to  this  clause. 
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7.5.2  Factor  constraints 

FACTOR:         ANY-PRESENTATION-STYLE  { 

REQ     Presentatlon-style-ldentlfier  {ANYVALUE}. 
PERM  User-readable-comments  {ANY_STRING}. 
PERM  User-vlslWe-name  {ANY  STRING}, 

} 

7.5.3  Presentation  style  constituent  constraint 
7.5.3.1  PStylel 

PStylel:  ANY-PRESENTATION-STYLE  { 

~  This  style  is  used  for  character  content  ~ 

PERM  Presentation-attributes  { 
PERM  #character-attributes  { 

PERM  #alignment  {ANY  VALUE}, 

PERM  #character-spacing      {ANY  VALUE}, 

PERM  #character-fonts         {ANY  VALUE}, 

PERM  #character-orientation  {'0-degrees'  |  '90-degrees'}. 

PERM  #character-path         {'0-degrees'     |     '90-degrees'    |  '180-degrees' 

'270-degrees'}, 
PERM  #code-extension-announcers  {$CDEXTEN}, 
PERM  #graphic-character-sets  {$PERMIT-GRCHAR}, 
PERM  #graphic-character-subrepertoire  {ANY  VALUE}, 
PERM  #graphic-rendition  {SGRAPHiCRENDITIONS}, 
PERM  #line-progression        {'90-degrees'  |  '270-degrees'}, 
PERM  #line-spacing  {ANY  VALUE}, 

PERM  #line-layout-table  {ANY_VALUE}}} 


7.5.3.2  PStyle2 

PStyle2:  ANY-PRESENTATION-STYLE  { 

-  This  style  is  used  for  geometric  graphics  content  - 

PERM  Presentation-attributes  { 

PERM  #geometric-graphics-attributes  { 

PERM  #picture-dinf^ensions  {ANY  VALUE}, 

PERM  #plcture-orientation  {ANY  VALUE}, 

PERM  #te>ct-rendition  {PERM  #fonts-llst{ANY_VALUE}, 
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PERM  #character-set-llst{ ANY_VALUE} } } } 


7.5.3.3  PStyle3 

PStyle3:  ANY-PRESENTATION-STYLE  { 

-  This  style  is  used  for  raster  grapliics  content  -- 

PERM  Presentation-attributes  { 

PERM   #raster-grapliics-attributes  { 

PERM  #pel-path  {ANY_VALUE}. 
PERM  #iine-progression  {ANY  VALUE}, 
PERM  #pel-spacing  {REQ  #iength  {ANY  VALUE}. 

REQ  #pel-spaces  {ANY  VALUE}}. 
PERM  #spacing-ratio   {REQ  #line-spacing-value  {ANY_VALUE}. 

REQ  #pel-spacing-vaiue  {ANY  VALUE}}. 
PERM  #ciipping  {ANY  VALUE}}} 

} 


7.6      Content  portion  constraints 


7.6.1       Macro  definitions 

DEFiNECTiLED."  ASN.1  {2837  5}")  -  Tiied  raster  encoding  - 


7.6.2       Factor  constraints 

No  factor  constraints  are  appllcabie  to  this  clause. 


7.6.3       Constituent  constraints 


7.6.3.1        Character  content  portion 

Character-content-portion  { 

REQ     Content-identifier^ayout  {ANYVALUE}. 

PERM  Type-of-coding  {ASN.1  {2  8  3  6  0}}. 

PERM  Alternative-representation  {ANY  STRING}, 

PERM  Content-information 

{CHARACTER.  {#STAB  {ANY  VALUE} 
|#SHS  {ANYVALUE} 
|#SGR  {$GRAPHICRENDITIONS} 
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|#SVS   {ANY  VALUE} 

|#SLS  {ANY"VALUE} 

|#SCS  {ANYVALUE} 

|#SRS  {ANY_VALUE} 

|#CR 

|#LF 

|#PLD 

|#PLU 

|#SP 

|#SUB 

|#LSO 

|#LS1R 

|#LS2R 

|#LS3R 

I  #SS2 

|#SS3 

I  #$DEG-CORE-G0 
j#$DEG-646-G0 
I  #$DEG-ANY-G1 
|#$DEG-ANY-G2 
I  #$DEG-ANY-G3 
I  #$DEG-EMPTY-G1 
}...} 

} 


7.6.3.2        Raster  graphics  content  portion 

Raster-graphics-content-portion  { 

REQ     Content-identifier-iayout  {ANYVALUE}, 

PERM  Type-of-coding  {  ASN.1  {2  8  3  7  0}  -  T.6  encoding  - 

I  ASN.1  {2  8  3  7  1}  ~  T.4  one  dimensional  - 
I  ASN.1{2  8  3  7  2}  ~  T.4  two  dimensional  ~  a 
I  ASN.1  {2  8  3  7  3}  ~  bitmap  encoding - 
I  ASN.1  {2  83  75}  ~ tiled  encoding  ~ 
I  ASN.1  {2  8  3  7  6}  ~  T.6  encoding  -  MSB  - 
I  ASN.1  {2  83  7  7}  ~ T.4  one  dimensional  -  MSB - 
I  ASN.1  {28378}  -  T.4  two  dimensional  -  MSB  -  }, 
PERM  Coding-attributes  { 

REQ     #raster-graphics-coding-attribLites  { 

PERM  #compression  {ANY  VALUE}, 

PERM  #number-of-lines  {>0}, 
REQ    #number-of-pels-per-line  {>0}, 
CASE  Raster-graphics-content-portion  (Type-of-coding)  OF  { 

{$TILED}:       {PERM  #numt)er-of-pels-per-tile-line 
PERM  #number-of-lines-per-tiie 
PERM  #tiling-offset 
PERM  #tile-types 


{512}. 
{512}. 

{ANYVALUE}, 
{'null  background'  | 
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'null  foreground'  | 
T.6  encoded'  | 
'bitnrtap  encoded'  | 
•T.6  encoded  -  MSB'}}}}, 


PERM  Alternative-representation 
PERM  Content-information 
} 


{ANYSTRING}. 
{RASTER} 


7.6.3.3 


Geometric  graphics  content  portion 


Qeometric-graphics-content-portion 

REQ  Content-identrfler-layout 

PERM  Type-of-coding 

PERM  Altemative-representatlon 

PERM  Content-information 

} 


{ 


{ANYVALUE}, 
{ASN.1{283  80}}. 


{ANYVALUE}. 
{GEOMETRIC} 


7.7     Additional  usage  constraints 

No  other  usage  constraints  are  currently  defined. 


8    interchange  format 

Two  interciiange  formats  are  supported  by  thiis  profile.  The  interchange  format  ODIF  (class  A)  can  be  used 
by  applications  requiring  a  binary  encoding  based  on  ASN.1.  The  Interchange  Format  SDIF  can  be  used 
by  applications  requiring  a  SGML  teased  clear  text  encoding.  This  latter  interchange  format  is  an  SGML 
application,  called  Office  Document  Language  (ODL).  For  the  purposes  of  interchange,  the  ODL  ENTITIES 
are  placed  in  an  ASN.1  wrapper,  as  defined  by  SDIF.  Each  encoding  form  has  inherent  advantages. 
Conversion  of  document  encoded  in  one  interchange  format  into  the  other  should  not  produce  the  loss  of 
semantic  document  information. 


8.1      Interciiange  format  ODIF  (class  A) 


8.1.1       Interciiange  format 

The  value  of  the  document  profile  attribute  "interchange  format"  for  this  interchange  format  is  'if-a'.  This  form 
of  ODIF  is  defined  in  ISO  8613-5. 

The  encoding  is  in  accordance  with  the  Basic  Encoding  Rules  for  Abstract  Syntax  Notation  One  (ASN.1), 
as  defined  in  ISO  8825. 
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8.1.2       DAP  Identifier 

The  value  for  the  document  profile  attribute  'document  application  profile"  for  this  interchange  format  Is 
represented  by  the  following  object  identifier. 

Editor's  Note  -  To  be  supplied. 


8.1.3       Encoding  of  application  comments 

ISO  8613-5  define  the  encoding  of  the  attritHJte  'application  comments"  as  an  octet  string.  For 
SpeciflcBlock,  this  DAP  requires  that  the  encoding  within  that  octet  string  be  in  accordance  with  the  ASN.1 
syntax  specified  In  the  following  module  definition. 

NIST-DAPSpecification 
;.   DEFINITIONS  ::=  BEGIN 

EXPORTS  Object-Appl-Comm-Encoding; 

Object-Appl-Comm-Eocoding  ::=  SEQUENCE  OF  INTEGER 
END 


8.2      interchange  format  SDIF 


8.2.1       interchange  format 

The  document  profile  attribute  'interchange  format"  does  not  apply  for  this  interchange  format.  The  SDIF 
encoding  of  ODA  Is  defined  in  Annex  E  of  ISO  8613-5.  in  addition,  ISO  8613-6,  -7,  and  -8  contain  additional 
specifications  for  this  encoding  of  ODA. 


8.2.2      DAP  Identifier 

The  value  for  this  attribute  "document  application  profile'  for  this  interchange  format  is  represented  by  the 
following  obfect  identifier. 

Editor's  Note  -  To  be  supplied. 


8.2.3       Encoding  of  application  comments 

For  SpeciflcBlock,  the  encoding  of  the  attribute  'application  comments"  is  defined  in  a  data  stream 
conforming  to  this  profile  with  the  following  DTD  definition: 

<!-  The  following  set  of  declarations  may  be  Invoked  by  using  a  public  entity  as  follows: 

<  IDOCTYPE  odaac  Public  "-//USA-01W//DTD  SGML  ENCODING  ODA  APPLICATION  COMMENTS//EN'> 
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-> 

<!~  NOTE:  To  parse  the  following  Document  Type  Declaration  Subset,  place  the  Document  Type 
declaration'  <!DOCTYPE  odaac  ['  at  the  beginning  of  the  file  and  "]>'  at  the  end  of  the  file.  -> 

<  {ELEMENT  odaac -- (ot}jappc)+  > 

<!-  Object  a|3pllcation  comment  -> 
<!ELEMENT  objappc  -  O  (#PCDATA)> 

8.3      Encoding  of  raster  content  information 

The  erK^oding  of  raster  content  information  in  the  bitmap  encoding  scheme  is  that  specified  in  9.3  of  the 
raster  graphics  content  architecture  part  of  ISO  8613-7,  that  is,  the  first  pel  in  the  order  of  bits  is  allocated 
to  the  most  significant  bit  of  an  octet.  The  encoding  of  the  code  words  in  the  CCITT  Recommendation  T.4 
and  T.6  encoding  schemes  may  be  done  in  either  the  up  or  down  bit  order.  The  bit  order  is  specified  by 
the  attributes  "type  of  coding"  or  tile  types".  The  attribute  "tile  types"  is  used  only  when  the  value  for  "type 
of  coding'  is  tiled  encoded'.  For  the  up  order.  It  is  such  that  the  first  or  only  bit  of  the  first  code  word  shall 
be  placed  in  the  least  significant  bit  of  the  first  octet.  Sut>sequent  tAts  of  the  first  and  following  code  words 
are  placed  in  the  direction  of  more  significant  bits  in  the  first  and  following  octets.  For  the  down  order,  it 
is  such  that  the  first  or  only  bit  of  the  first  code  word  shall  be  placed  in  the  most  significant  bit  (MSB)  of  the 
first  octet.  Subsequent  bits  of  the  first  and  following  code  words  are  placed  in  the  direction  of  least 
significant  bits  In  the  first  and  following  octets. 
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Annex  A  (normative) 
Amendments  and  corrigenda 

A.1  Amendments 

A.1.1      Amendments  to  the  base  standard 

The  amendments  applicable  to  this  DAP  indudes  the  BSO  8613  -  Amendment  1:  1990.  This  amendment 
Includes  text  to  be  included  In  ISO  8613-1  as  the  following  annexes: 

a)  Annex  E:  Use  of  ISO/IEC  10021  (MOTIS)  to  interchange  documents  confomning  to  ISO  8613; 

b)  Annex  F:  Document  application  profile  proforma  and  notation; 

c)  Annex  G:  Conformance  testing  methodology; 

d)  Annex  M:  Recording  of  documents  conforming  to  ISO  8613  on  flexible  disk  cartridges 
conforming  to  ISO  9293. 

In  addition,  this  amendment  addresses  the  inclusion  of  the  ISO  8613  Technical  Corrigenda  1. 

This  DAP  does  not  include  the  fdiowing  features  of  the  amendment: 

a)  Addendum  on  security; 

b)  Addendum  on  styles; 

c)  AdderxJum  on  alternative  representation. 

Additionally,  this  DAP  includes  features  from  the  Tiled  Raster  Graphics  Addendum  to  ISO  8613-7.  ISO/EC 
JTC1/SC18/WG5  901,  dated  September  1990,  and  the  Additional  Bit  Order  Mapping  Addendum  to  CCitT 
Rec.  T.417|!SO  8613-7,  ISO/IEC  JTC  1/WG  3,  dated  July  1991.  A  new  version  of  ISO  8613-7  which  also 
will  incorporate  the  Colour  Addendum  is  scheduled  to  be  issued  in  1993. 

A.2  Corrigenda 

A.2.1       Corrigenda  to  this  DAP 

There  are  no  corrigenda  to  this  DAP. 
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Annex  B  (informative) 
Recommended  practices 


B.1      Transfer  methods  for  ODA 


B.1.1       Conveyance  of  ODA  over  CCITT  X.400-1984 

This  recommendation  describes  how  ODA  body  parts  are  to  be  encoded  for  transmission  over  a  CCITT 
X.400-1984  service. 

An  ODA  body  part  Is  encoded  as  OdaBodyPart  In  the  definition  given  below: 


OdaBodyPart  ::=  SEQUENCE  {  OdaBodyPartParameters,  OdaData  } 
OdaBodyPartParameters  ::=  SET  { 
document-application-profile 

[0]  IMPLICIT  OBJECT  IDENTIFIER, 
document-architecture-class 

[1]  IMPLICIT  INTEGER  { 
formatted  (0), 
processable  (1), 
formatted-processaWe  (2)  } 
OdaData  ::=     SEQUENCE  OF  Interchange-Data-Element 


NOTE  -  It  is  recommended  to  transfer  an  ODA  document  as  a  single  txxjy  part  with  tag  12: 
Oda  [12]  IMPLICIT  OCTETSTRING 

The  content  of  the  octet  string  Is  encoded  as  OdaBodyPart,  defined  above.  However,  this  Is  out 
of  the  scope  of  this  profile. 

B.1 .2       Conveyance  of  ODA  over  FTAM 

This  recommendation  describes  the  File  Transfer,  Access,  and  Management  (FTAM)  Document  Type  to  be 
used  for  minimal  storage  and  transfer  capabilities  of  ODA  data  streams.  It  Is  recognized  that  enhanced 
capabilities  may  at  some  point  be  added. 

When  using  FTAM  to  transfer  an  ODA  file,  the  FTAM-3,  "ISO  FTAM  Unstructured  Binary",  document  type 
should  be  specified.  However,  since  files  that  do  not  contain  ODA  data  streams  can  have  the  same 
document  type,  it  is  left  up  to  the  user  of  application  programs  that  remotely  access  files  using  FTAM  to 
know  that  a  given  file  contains  an  ODA  data  stream. 
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B.1 .3      Conveyance  of  ODA  over  DTAM 

This  recommendation  provides  for  information  concerning  the  interchange  of  ODA  based  documents  with 
Document  Transfer  and  Manipuiation  (DTAI\^)  protocols. 

DTAM  is  defined  in  the  T.430-Series  of  recommendations  and  is,  lii<e  ODA,  an  integral  part  of  the  T.400- 
Series  of  CCITT  Recommendations  named  Open  Document  Architecture,  Transfer  and  Manipulation. 

The  T.520-Serles  of  recommendations  contain  Communication  Application  Profiles  (CAP).  Recommendation 
T.522  describes  the  Communication  Application  Profile  BT1  for  document  bulk  transfer.  Recommendation 
T.522  is  applicable  for  the  Office  Document  Format  Profile  (FOD)  published  in  this  ISP. 

NOTE  -  The  use  of  BT1  within  the  end-toend  oriented  Telematic  Services  Telefax  4  and  Teletex  is  descrit>ed 
in  7.1  of  Recommendation  T.561  and  7.1  of  Recommendation  T.562. 


B.1.4       Conveyance  of  ODA  over  flexible  disks 

The  recommended  method  for  interchanging  ODA  documents  between  systems  by  the  exchange  of 
magnetically  recorded  Flexible  Disk  Cartridges  is  by  the  use  of  an  annex  to  ISO  8613-1  (to  be  published), 
Recoding  of  Documents  Conforming  to  ISO  8613  on  Flexible  Cartridges  Conforming  to  ISO  9293.  This 
annex  provides  for  recording  each  ODA  document  as  a  separate  file  as  defined  by  ISO  9293,  Volume  and 
File  Structure  of  Flexible  Disk  Cartridges  for  Information  Interchange. 

NOTE  -  Document  encoded  in  ODL  can  be  stored  such  that  each  SGML  ENTITY  is  recorded  in  a  separate 
file  or  in  the  case  of  an  SDIF  encoding,  the  file  can  be  stored  in  a  single  file. 

B.2      Font  reference 

The  recommended  method  for  specifying  a  font  reference  is  to  be  t>ased  on  ISO  9541.  Such  a  reference 
is  to  be  specified  by  the  following  ASN.I  encoding. 

Fonts-Reference      ::=        SET  { 

user-visible-name  (0)  IMPLICIT  Comment-String  OPTIONAL, 

user-readable-comment  (1)  IMPLICIT  Comment-String  OPTIONAL, 
reference-attributes  (2)  IMPLICIT  SET  OF  SET  { 

precedence-number  (0)  IMPLICIT  INTEGER  OPTIONAL, 

attributes  (1)  IMPLICIT  Font-Attribute-Set, 

user-readable-comment        (2)  IMPLICIT  Comment-String  OPTIONAL  } 

} 

Font  sizes  from  6  to  72  points  (100  to  1200  BMU)  are  intended  to  be  supported  by  implementation 
conforming  to  this  informative  recommendation.  All  other  values  of  font  sizes  may  additionally  be  supported, 
but  implementations  may  also  support  using  some  form  of  "fallback". 

The  minimum  font  properties  and  values  from  ISO  9541  that  are  to  be  specified  in  a  Font-Attribute-Set  be 
those  specified  by  the  following  document  application  profile  notation. 

Font-Attribute-Set  { 

PERM     Fontname  {ANYVALUE}, 
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PERM 
PERM 
PERM 
PERM 
PERM 
PERM 
PERM 


PERM 
PERM 


PERM 


PERM 


PERM 
PERM 


Standardversion 

Dsnsource 

Fontfamily 

Posture 

Weight 

Propwidth 

Glyphcomp 

PERM  #inclgyphcols 

PERM  #exclgyphcols 

PERM  #inclgyphs 

PERM  #exclgyphs 

Dsnstze 

Minsize 

PERM  #numerator 
PERM  #denominator 
Maxsize 

PERM  #numerator 

PERM  #denominator 

-  BMU  Units  equivalent  to  range  of  6. 

IDsngroup 

PERM  #group-code 
PERM  #sut)group-code 
PERM  #specific-group-code 
Structure 
Wrmodes 

PERM  #wrmodename 
PERM  #nomescdir 
PERM  #e8class 
PERM  #avgescx 
PERM  #avge8cy 


{-  To  be  supplied  -}, 

{/LVALUE}, 

{ANY_VALUE}, 

{'upright'  I  'italic-forward'}, 

{'light'  I  'medium'  |  'bold'}, 

{ANYVALUE}, 

{ 

{ANY  VALUE}, 
{ANY'VALUE}, 
{ANY~VALUE}, 
{ANY  VALUE}  }, 

{ANYVALUE}, 

{ 


{1}}. 


{ 


{100 ..  1200}, 


{100  ..  1200}, 


{1}}. 
72  point  sizes  - 

{ 

{ANYVALUE}, 
{ANYVALUE}. 
{ANY  VALUE}  }. 

{ANYVALUE}, 

{ 

{ANYVALUE}. 

{'0<legrees' 
{ANYVALUE}. 
{ANYVALUE}. 
{ANY  VALUE}  } 


'90<legrees'  |  '180-degrees'  |  '270-degrees'}, 


B.3      ISO  8632  (CGM)  constraints  for  this  DAP 

It  is  recommended  that  geometric  graphics  content  information  contain  only  those  elements  listed  in  this 
portion  of  the  document,  in  addition  to  the  constraints  imposed  by  ISO  8613-8.  It  is  believed  that  this  subset 
of  the  CGM  is  sufficiently  implemented  to  enable  IntenA^orking  of  geometric  graphics  for  application 
conforming  this  document  application  profile. 

Where  an  element  has  parameters,  recommended  constraints  on  the  values  are  given.  The  symbol 
Indicates  that  there  is  no  recommended  constraint. 

Requirements  in  ISO  8632  and  ISO  8613-8  concerning  mandatory  elements,  parameters  must  be  fulfilled. 


B.3.1       Delimeter  elements 

No-Op  See  Note  1 

Begin  Metafile  See  Note  2 

End  Metafile 

Begin  Picture  See  Note  2 

Begin  Picture  Body 
End  Picture 
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B.3.2       Metafile  descriptor  elements 


Metafile  Version 
Metafile  Description 
VDC  Type 
Integer  Precision 
Real  Precision 
Index  Precision 
Colour  Precision 
Colour  IrxJex  Precision 
Maximum  Colour  Index 
Colour  Value  Extent 
Metafile  Element  List 
Font  List 

Character  Set  List 
Character  Coding  Announcer 


1 

See  Notes  2,  3 
8,  16 

(0.9,23).  (1.16.16) 
16 

8.  16 
8.  16 


See  Note  5 

0.  (basic-7-blt),  (basic-8-bit) 


B.3.3       Picture  descriptor  elements 

Scaling  Mode  See  Note  6 

Colour  Selection  Mode 

Line  Width  Specification  Mode  - 
Marker  Size  Specification  Mode  - 
Edge  Width  Specification  Mode 
VDC  Extent 
Bacl<ground  Colour 


B.3.4       Control  elements 

VDC  Integer  Precision  16,  32 

VDC  Real  Precision  (0,9,23),  (1,16,16) 

Auxiliary  Colour 

Transparency 

Clip  Rectangle 

Clip  Indicator 


B.3.5       Graphical  primitive  elements 

Polyline  See  Note  7 
Disjoint  Polyline  See  Note  7 

Polymarker  See  Note  7 

Text  See  Note  2 
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Restricted  Text  See  Notes  2,  8 

Append  Text  See  Notes  2,  8 

Polygon  See  Note  7 

Polygon  Set  See  Note  7 

Cell  Array  See  Note  9 

Rectangle  - 
Circle 

Circular  Arc  3  Point  - 

Circular  Arc  3  Point  Close  - 

Circular  Arc  Centre  - 

1  Circular  Arc  Centre  Close  - 

Ellipse  - 
Elliptical  Arc 

Elliptical  Arc  Close  - 


B.3.6      Attribute  elements 


Line  Bundle  Index 

Line  Type 

Line  Width 

Line  Colour 

Marker  Bundle  Index 

Marker  Type 

Marker  Size 

Marker  Colour 

Text  Bundle  Index 

Text  Font  Index 

Text  Precision 

Character  Expansion  Factor 

Character  Spacing 

Text  Colour 

Character  Height 

Character  Orientation 

Text  Path 

Text  Alignment 

Character  Set  Index 

Alternate  Character  Set  Index 

Fill  Bundle  Index 

Interior  Style 

Fill  Colour 

Hatch  Index 

Pattern  IrxJex 

Edge  Bundle  Index 

Edge  Type 

Edge  Width 

Edge  Colour 

Edge  Visibility 


1-5 
1-5 

positive 

1-5 
1-5 


1-5 


positive 


1-5 


1-6 

1  ..  8,  nx  1-16.  ny  1-16 

1-5 

1-5 

positive 
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FHI  Reference  Point 

Pattern  Table  See  Notes  10,  11 

Pattern  Size 

Colour  Table  Specification  See  Notes  12,  13 

Aspect  Source  Rags  - 


B.3.7      External  elements 


Message  No  action 

Application  Data  See  Note  2 


NOTE- 

1.  An  arbitrary  sequence  of  n  octets.  Where  n =0, 1 , ..,  32767.  The  sequence  of  zero  or  more  octets  is  for  padding 
purposes. 

2.  The  string  ocurring  in  the  parametric  list  of  this  element  shall  not  contain  more  than  254  characters,  except  for 
data  records  where  the  string  shall  not  contain  more  than  32767  characters. 

3.  There  will  be  exactly  one  METAFILE  DESCRIPTION  element  in  the  metafile.  The  METAFILE  DESCRIPTION  string 
parameter  will  be  used  to  include  the  sub-string  "ISO  FCG13"  to  label  the  content  information  as  conforming 
to  this  agreement.  In  addition,  the  METAFILE  DESCRIPTION  element  should  include  a  sub-string  that  identifies 
the  generator  of  this  metafile,  including  company,  product,  and  product  version. 


4.  The  only  character  sets  that  may  be  specified  are  those  specified  for  character  content  portions.  Refer  to  7.1, 

Document  Profile  Constraints,  for  further  detail  on  which  character  sets  are  supported  by  this  document 
application  profile.  The  default  character  set  for  geometric  graphics  content  is  the  same  as  the  default  character 
set  for  character  content  architecture. 


5.  The  Scale  Factor  parameter  of  SCALING  MODE  element  is  always  a  32-bit  floating  point  value,  even  when  the 
REAL  PRECISION  has  selected  fixed  point  for  other  real  numbers.  It  is  not  apparent  in  ISO  8632  what  the 
precision  of  this  floating  point  value  Is  when  fixed  point  has  been  selected.  Its  precision  shall  be  (0,9,23). 

6.  The  maximum  number  of  points  of  this  element  shall  be  1024. 

7.  '  The  complete  restricted  text  string,  including  any  appended  text,  shall  be  included  in  a  metafile  conforming  to 

this  agreement.  The  complete  restricted  text  string  shall  be  scaled  isotropically  such  that  the  specified  aspect 
ratio  for  the  text  is  not  distorted  and  the  string  fits  into  the  text  extent  parallelogram.  String  of  parameters  shall 
not  contain  any  control  characters  except  as  allowed  by  and  necessary  to  implement  the  character  set  switching 
modes  which  can  be  selected  by  basic  values  of  CHAR  CODE  ANNOUNCER. 

8.  The  maximum  number  of  colour  values  that  can  appear  in  the  colour  list  parameter  for  the  CELL  ARRAY 
element  shall  be  1048576  (one  1024  x  1024  image). 

9.  The  PATTERN  TABLE  element  shall  appear  prior  to  any  graphical  primitive  element  to  assure  that  interpreting 
systems  without  dynamic  pattern  update  can  render  the  intended  effect.  Once  a  given  pattern  representation 
is  specified  and  used,  it  shall  not  be  respecified. 

10.  Colour  Array  parameter  for  the  PATTERN  TABLE  element  is  2048.  This  will  support  8  patterns  of  16x16.  The 
maximum  number  of  colour  values  that  can  appear  in  a  colour  array  parameter  shall  be  256  for  each  PATTERN 
TABLE  element  (one  16x16  pattern)  and  2048  for  the  complete  pattern  table  itself  (eight  16x16  patterns). 


1 1 .         The  COLOUR  TABLE  element  shall  appear  prior  to  any  graphical  primitive  elements  to  assure  that  interpreting 
systems  without  dynamic  colour  update  can  render  the  intended  effect.  Once  a  given  colour  representation  is 
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specified  and  used,  it  shall  not  be  respecified.  For  indexed  colour  selection,  either  background  colour  or  ail 
colour  indexes  in  the  metafile  shall  have  their  representations  specified  or  none  shall.  Colour  indexes  shall  be 
specified  by  the  COLOUR  TABLE  elennent.  Background  colour  shall  be  specified  either  by  the  BACKGROUND 
COLOUR  element  or  the  the  colour  index  0.  For  direct  colour  selection,  either  the  background  colour  or  the 
colour  of  each  displayed  primitvie  shall  be  explicitly  specified,  or  none  shall  be  specified,  ki  other  words,  either 
all  colours  shall  be  defaulted  or  none  shall  be  defaulted. 

12.         The  maximum  number  of  colour  values  that  can  appear  in  the  Colour  List  parameter  for  the  COLOUR  TABLE 
element  is  64.  This  will  support  a  63  entry  colour  table. 


B.4     Interoperability  with  SGML  applications 

The  recommended  methcxJ  for  the  exchange  of  documents  between  Standard  Generalized  Markup 
Language  (ISO  8879,  SGML)  based  systems  and  systems  based  on  this  ODA  document  application  profile 
is  by  means  of  exchanging  a  document  representation  conforming  to  these  agreements  in  an  encoded  form 
of  the  SGML  language  known  as  the  Office  Document  Language  (ODL).  ODL  is  a  standardized  SGML 
application  for  representing  documents  conforming  to  the  ODA  base  standard.  Such  a  representation  can 
be  converted  into  the  Office  Document  Interchange  Format  (ODIF)  supported  by  this  document  application 
profile. 
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Annex  C  (informative) 

References  to  other  standards  and  registers 

[I]  CCITT  Recommendation  T.400  :  1988.  Introduction  to  Document  Architecture.  Transfer  and 
Manipulation; 

[2]       CCITT  Recommendation  T.41 1 : 1 988,  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Introduction  and  General  Principles; 

[3]       CCITT  Recommendation  T.41 2 : 1 988,  Open  Document  Architecture  (ODA)  and  interchange  Format: 
Document  Structures; 

[41       CCITT  Recommendation  T.41 4 : 1 988.  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Document  Profile; 

[5]       CCITT  Recommendation  T.41 5 : 1 988,  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Open  Document  Interchange  Format; 

[6]       CCITT  Recommendation  T.41 6 : 1 988,  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Character  Content  Architecture; 

[7]       CCITT  Recommendation  T.41 7 : 1 988,  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Raster  Graphics  Content  Architecture; 

[8]       CCITT  Recommendation  T.41 8 : 1 988,  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Geometric  Graphics  Content  Architecture; 

[91       CCITT  Recommendation  T.502  :  1990,  Document  Application  Profile  PM-11  for  the  Interchange  of 
Character  Content  Documents  in  Processable  and  Formatted  Forms; 

[10]     CCITT  Recommendation  T.503  :  1984,  Document  Application  Profile  for  the  Interchange  of  Group 
4  Facsimile  Documents; 

[II]  CCITT  Recommendation  T.505  :  1990.  Document  Application  Profile  PM-26  for  the  Interchange  of 
Enhanced  Mixed  Content  Documents  in  Processable  and  Fornriatted  Forms; 

[12]     ISO  8571  :  1988.  Information  processing  systems  -  Open  Systems  Interconnection  -  File  transfer, 
access  and  management; 

[13]     ISO  9070  :  1990,  Information  processing  -  SGML  support  facilities  -  Registration  procedures  for 
public  owner  Identifiers; 

[14]     ISO/TR  9573  : 1 988,  Information  processing  -  SGML  technical  report  -  Techniques  for  using  SGML; 

[15]     ISO  10021  :  (to  be  published).  Information  processing  systems  -  Text  communication  -  Message 
Oriented  Text  Interchange  System; 
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[16]     ISP  F0D1 1  :  (to  be  published),  Office  document  format  profile  for  the  interchange  of  basic  function 
character  content  document  in  processaWe  and  formatted  forms; 

[17]     ISP  FOD26  :  (to  be  published),  Office  document  format  profile  for  the  interchange  of  enhanced 
function  mixed  content  documents  in  processable  and  formatted  forms; 

[18]     ISP  FOD36  :  (to  be  published),  Office  document  format  profile  for  the  interchange  of  extended 
function  mixed  content  documents  in  processable  and  formatted  forms; 

[19]      MIL-R-28002A  :  1990,  MILITARY  SPECIFICATION,  RASTER  GRAPHICS  REPRESENTATION  IN 
BINARY  FORMAT,  REQUIREMENTS  FOR. 


53 


PART  22  -  ODA  Image  DAP 


December  1992  (Stable) 


Annex  D  (informative) 

Supplementary  information  on  attributes 


Table  D.I  Content  coding  attributes 


Attributes 

Basic  values 

DefauH  values 

Non-basic 
values 

Number-of-pels-per-line 

any  positive  integer 

None 

None 

Number-of-lines 

any  positive  integer 

None 

None 

Tiling-offset* 

(any  non-negative  integer 
<  512,  any  non-negative 
integer  <  512) 

(0.0) 

None 

Tile-types* 

T.6  encoded,  bitmap 
encoded,  null 
background,  null 
foreground,  T.6  encoded  - 
MSB 

T.6  encoded 

None 

Type-of-coding 

T.6  encoding  (untiled), 
bitmap  (untiled),  tiled 
encoded,  T.4  ID 
encoding,  T.4  2D 
encoding,  T.6  encoding  - 
MSB  (untiled),  T.4  ID 
encoding  -  MSB,  T.4  2D 
encoding  -  MSB 

T.6  encoding,  T.6 
encoding  -  MSB,  tiled 
encoding  ** 

None 

Tutorial  Note  -  *  Only  used  if  type  of  coding'  is  'tiled  encoded' 


Tutorial  Note  -  **  As  specified  in  the  document  profile 


Table  D.2  Presentation  attributes 


Attributes 

Basic  values 

Default  values 

Non-basic  values 

Pel-path 

0,  90  deg 

0  deg 

180,  270  deg 

Line-progression 

270  deg 

270  deg 

90  deg 

Pel-spacing 

16,  12,  8,  6,  5,  4,  3,  2,  1 
BMU 

4  BMU  (300) 

Any  value  except 
'null- 

Clipping 

Two  Coordinate  Pairs 
(any  non-negative  integer, 
any  non-negative  integer) 

(0,0),  (N-1,  L-1) 

None 
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Table  D.3  Document  profile  attributes 


rBrnileSIDIB  ValUBo 

0|Jvwiiii>^ioy wui  oil  uv>iui 

1 1 1 

riBSoriiaiiori-siyios 

nrn 

i^ocurnoni-cnaiaciorioiics 

LI 
IVI 

Document-architecture-class 

m 

formatted 

Document-application-profile 

m 

{-  See  clause  8  for  a  definition  of  the 
permitted  values  for  this  attribute.  -} 

Content-architecture-classes 

m 

{2  8  2  7  2},  {2  8  2  8  0},  {2  8  2  6  0} 

Interchange-format-class 

m 

A 

ODA-version 

m 

ISO  8613.  1991-12-31 

Document-architecture-defaults 

M 

Content-architecture-class 

m 

formatted  processable  raster  graphics 

Type-of-coding 

m 

T.6  encoding,  tiled  encoding,  T.6 
encoding  -  MSB 

Page-dimensions 

nm 

See  list  in  table  1 ,  (Default  value  is  NA- 
A,  9240  X  13200  BMU) 

Medium-types 

nm 

See  list  in  table  1 ,  (Default  value  is  NA- 
A,  9240  X  13200  BMU) 

Page-position 

nm 

any  coordinate  pair  within  page 

Raster-gr-content-defaults 

NM 

Pel-path 

nm 

0,  90,  180,  270  degrees  (0  is  normal 
default) 

Line-progression 

nm 

90,  270  degrees  (270  is  normal  default) 

Pel-spacing 

nm 

16,  12,  8,  6,  5,  4,  3,  2,  or  1  BMU 
(Normal  default  is  4  BMU) 

Spacing  Ratio 

nm 

Any  value 

f>Jon-basic-doc-characteristics 

NM 

Page-dimensions 

nm 

See  table  1 

Medium-types 

nm 

See  table  1 
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Table  D.3  Document  profile  attributes  (concluded) 


Attribute 

Class 

Permissible  values 

Raster-gr-presentation-features 

NM 

Pel-path 

nm 

180,  270  degrees 

Line-progression 

nm 

90  degrees 

Pel-spacing 

nm 

16,  12,  8,  6,  5.  4,  3.  2,  or  1  BMU 

Document-management-attributes 

M 

Document  Reference 

m 

Any  string  of  characters 

The  following  notation  is  used  in  the  class  column  of  this  tat>ie: 

a)  m   mandatory  attribute 

b)  nm  non-mandatory  attribute 

c)  d  defaultabie  attribute 

Capital  letters  (M,  NM,  and  D)  are  used  for  groups  of  attributes. 
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Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Office  Document  Architecture  (ODA) 
Special  Interest  Group  (SIG)  of  the  Open  Systems  Environment  Implementors'  Workshop  (OIW). 
Development  of  this  document  application  profile  has  been  done  in  liaison  with  several  organizations.  These 
include  the  DoD  Computer-aided  Acquisition  and  Logistic  Support  (GALS)  Office,  Navy's  David  Taylor 
Research  Center,  and  the  ad-hoc  Tiling  Task  Group. 

This  document  application  profile  is  intended  to  be  suitable  for  the  interchange  of  large  format  raster  images. 
This  part  contains  four  annexes: 

a)  annex  A  (normative):  Amendments  and  corrigenda; 

b)  annex  B  (informative):  Recommended  practices; 

c)  annex  C  (informative):  References  to  other  starxJards  and  registers; 

d)  annex  D  (informative):  Supplementary  information  on  attributes. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  a  new 
part.  Deleted  and  replaced  text  will  be  shown  as  struckout.  New  and  replacement  text  will  be  shown  as 
shaded. 

This  part  uses  a  convention  of  double  and  single  quotes  that  has  been  established  by  ISO  for  use  in  the 
ODA  base  standard  and  related  document  application  profiles.  The  convention  is  to  use  within  the  text 
double  quotes  to  accentuate  ODA  attribute  names  and  single  quotes  to  accentuate  values  for  those 
attributes. 
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Part  23  -  ODA  Raster  DAP 


0  Introduction 

This  is  the  definition  of  a  specification  for  an  Open  Document  Architecture  (ODA)  Document  Application 
Profile  (DAP)  named  ODA  Raster  DAP.  This  DAP  is  suitable  for  interchanging  documents  in  formatted  form. 
The  documents  contain  only  raster  graphics  images. 

There  are  two  DAP  object  identifiers  supporting  this  DAP  with  the  only  difference  being  in  the  encoding  of 
the  data  stream.  One  uses  the  ASN.1  based  ODIF  encoding.  The  other  uses  the  SGML/SDIF  based  ODL 
encoding.  When  this  document  refers  to  this  profile,  it  is  referring  to  this  specification  regardless  of  which 
DAP  identifier  may  be  selected  to  create  the  data  stream. 

This  DAP  tias  been  prepared  by  the  ODA  Special  Interest  Group  (SIG)  of  the  Open  Systems  Environment 
Implementors'  Workshop  (OIW).  The  DAP  is  defined  in  accordance  with  ISO  8613-1  and  follows  the 
standardized  proforma  and  notation  defined  in  ISO  8613-1  Annex  F.  The  DAP  is  based  on  ODA  as  defined 
in  ISO  8613  and  the  Tiled  Raster  Graphics  Addendum  to  ISO  8613,  Part  7. 


1     Scope  and  field  of  applications 

This  DAP  specifies  an  interchange  format  suitable  for  transfer  of  structured  documents  between  equipment 
designed  for  raster  processing.  The  documents  supported  by  this  DAP  are  based  on  a  paradigm  of  an 
electronic  engineering  drawing  or  illustration.  Such  documents  contain  one  or  more  pages.  Each  page 
consists  of  an  Image  in  the  form  of  a  bi-tonal  raster  graphics  content.  There  is  no  restriction  on  the 
minimum  size  of  the  image. 

This  document  defines  a  DAP  that  allows  large  format  raster  documents  to  be  interchanged  in  a  formatted 
form  in  accordance  with  ISO  8613. 

It  is  assumed  that,  when  negotiation  is  performed  by  the  service  using  this  DAP,  all  non-basic  values  are 
subject  to  negotiation. 

This  DAP  is  independent  of  the  processes  carried  out  in  an  end  system  to  create,  edit,  or  reproduce  raster 
documents.  It  is  also  independent  of  the  means  to  transfer  the  document  which,  for  example,  may  be  by 
means  of  communication  links  or  exchanged  storage  media. 

The  features  of  a  document  that  can  be  interchanged  using  this  DAP  fall  Into  the  following  categories: 

a)  Page  format  features  -  these  concern  how  the  layout  of  each  page  of  a  document  will  appear 
when  reproduced; 

b)  Raster  graphics  layout  and  imaging  features  -  these  concern  how  the  document  content  will 
appear  within  pages  of  the  reproduced  document; 

c)  Raster  graphics  coding  -  these  concern  the  raster  graphics  representations  and  control 
functions  that  make  up  the  document  raster  graphics  content. 
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2     Normative  references 

The  following  references  are  required  in  order  to  Implement  this  DAP: 

2.1  ISO 

[  1  ]       ISO  861 3-1  : 1 989,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  1:  Introduction  and  General  Principles; 

y      [2]       ISO  861 3-2  : 1 989,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  2:  Document  Structures; 

[3]       ISO  861 3-4  : 1 989,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  4:  Document  Profile; 


[4]  ISO  861 3-5  : 1 989,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  5:  Open  Document  Interchange  Format; 

[5]  ISO  861 3-7 : 1 989,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  7:  Raster  Graphics  Content  Architectures; 

[6]  ISO  861 3-1  : 1 991 .  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  1:Annex  F  -  A  Document  Application  Profile  Proforma  and 
Notation; 

[7]  ISO  861 3-7 :  (to  be  published).  Information  processing  -  Text  and  Office  Systems;  Office  Document 
Architecture  (ODA)  and  Interchange  Format  -  Part  7:  Amendment-  Tiled  Raster  Graphics  Addendum 
to  ISO  8613,  Part  7; 

[8]  ISO  861 3-7 :  (to  be  published).  Information  processing  -  Text  and  Office  Systems;  Office  Document 
Architecture  (ODA)  and  Interchange  Format  -  Part  7:  Amendment  -  Additional  Bit  Order  Mapping 
Addendum; 

[9]  ISO  8824  :  1987,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Specification 
of  Abstract  Syntax  Notation  One  (ASN.  1); 


[10]      ISO  8825  :  1987,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Specification 
of  Basic  Encoding  Rules  for  Abstract  Syntax  Notation  One  (ASN.  1); 

[11]     ISO  8879  : 1 986,  Information  processing  -  Text  and  office  systems  -  Standard  Generalized  Markup 
Language  (SGML); 

[12]     ISO  8879  :  1986,  Information  processing  -  Text  and  office  systems  -  Standard  Generalized  Markup 
Language  (SGML),  Amendment  1; 

[13]      ISO  9069  :  1988,  Information  processing  -  SGML  support  facilities  -  SGML  Document  Interchange 
Format  (SDIF). 
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2.2  CCITT 

[14]     Recommendation  T.4  :  1988,  Standardization  of  Group  3  Facsimile  Apparatus  for  Document 
Transmission. 

[15]     Recommendation  T.6  :  1 988,  Facsimile  Coding  Sciiemes  and  Coding  Control  Functions  for  Group 
4  Facsimile  Apparatus. 


3     Definitions  and  terminology 


3.1  Definitions 

The  definitions  given  in  ISO  8613-1  are  apolicable  to  this  document. 


3.2      Constituent  names 

Each  constituent  that  may  be  included  in  a  document  that  conforms  to  this  profile  has  been  given  a  unique 
name  which  serves  to  identify  that  constituent  throughout  this  profile. 

The  convention  is  that  full  names  are  used  (i.e.,  no  abbreviations  are  used),  two  or  more  words  in  a  name 
are  concatenated  and  each  word  begins  with  a  capital.  Examples  of  constituent  names  used  In  this  profile 
are  CompositePage,  DocumentLayoutRoot,  and  SpecificBlock. 

In  clause  6,  each  constituent  provided  by  this  profile  is  underlined  once  at  the  point  in  the  text  at  which  the 
purpose  of  that  constituent  Is  defined.  This  also  serves  to  Identify  all  the  constituents  provided  by  this 
profile. 

The  same  constituent  names  are  also  used  in  the  technical  specification  in  clause  7  so  that  there  is  a 
one-to-one  correspondence  between  the  use  of  these  names  in  clauses  6  and  7. 

Although  the  constituent  names  relate  to  the  purpose  of  the  constituents,  the  semantics  of  constituents  must 
not  be  implied  from  the  actual  names  that  are  used.  Also,  these  names  do  not  appear  in  an  interchanged 
document  but  a  mechanism  for  identifying  constituents  in  an  interchange  document  is  provided.  Thus  in 
an  application  using  this  profile,  the  constituents  may  be  known  to  the  user  by  different  names. 
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4     Relationship  to  other  DAPs 

Functionally,  this  DAP  Is  a  functional  superset  of  the  CX^ITT  Recommendation  T.503,  A  Document  Application 
Profile  for  the  Interchange  of  Group  4  Facsimile  Documents.  This  DAP  Is  a  functional  subset  of  Part  22  - 
ODA  Image  DAP. 


5  Conformance 

In  order  to  conform  to  this  DAP,  a  data  stream  representing  a  document  must  meet  the  requirements 
specified  In  5.1. 

The  requirements  for  implementations  that  originate  and/or  receive  data  streams  conforming  to  this  DAP 
are  specified  in  5.2. 


5.1      Data  stream  conformance 

The  following  requirements  apply  to  the  encoding  of  data  streams  that  conform  to  these  agreements: 

a)  The  data  stream  shall  be  encoded  In  accordance  with  the  ASN.1  encoding  rules  defined  In 
ISO  8825  or  the  SGML  grammar  and  syntax  of  ISO  8879; 

b)  The  data  stream  shall  be  structured  in  accordance  with  the  interchange  format  defined  In 
clause  8; 

c)  The  document  shall  be  structured  in  accordance  with  only  the  formatted  document 
architecture  class  specified  in  clause  7.  In  addition,  the  document  shall  contain  all  mandatory 
constituents  specified  for  that  class  and  nr^y  optionally  contain  constituents  permitted  for  that 
class  as  specified  in  clause  7; 

d)  Each  constituent  shall  contain  all  those  attributes  specified  as  required  for  that  constituent  In 
this  profile.  Other  attributes  may  be  specified  provided  they  are  permitted  for  that  constituent; 

e)  The  attributes  shall  have  values  within  the  range  of  permissible  values  specified  in  this  profile; 

f)  The  encoded  document  shall  be  structured  in  accordance  with  the  abstract  document 
architecture  defined  In  ISO  8613-2; 

g)  The  encoded  document  shall  be  structured  In  accordance  with  the  characteristics  defined  in 
clause  6  and  shall  contain  only  those  features  defined  In  clause  6. 
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5.2      Implementation  conformance 

This  clause  states  the  requirements  for  implementations  claiming  conformance  to  this  DAP. 

A  conforming  receiving  Implementation  must  t>e  capable  of  receiving  either  any  data  streams  conforming 
to  this  profile  structured  in  accordance  with  ODIF  or  any  data  streams  conforming  to  this  profile  structured 
in  accordance  with  ODL  or  both  of  these.  Receiving  usually,  but  not  always,  involves  recognizing  and 
further  processing  the  data  stream  elements. 


6    Characteristics  supported  by  this  DAP 

This  clause  describes  the  characteristics  of  documents  that  can  be  represented  by  data  streams  conforming 
to  this  profile.  This  clause  also  describes  how  these  characteristics  are  represented  In  terms  of  divisional 
components  of  the  data  streams. 


6.1  Overview 

This  DAP  describes  the  features  of  ISO  8613  that  are  needed  to  support  the  interchange  of  documents 
containing  only  raster  graphics  content.  It  specifies  interchange  formats  for  the  transfer  of  structured 
documents  with  simple  layout  structures. 

This  DAP  describes  documents  that  can  be  interchanged  in  the  formatted  form,  which  facilitates  the 
reproduction  of  a  document  as  intended  by  the  originator. 

Only  one  category  of  content  is  allowed  within  the  document,  that  Is,  a  raster  graphics  content  in  the 
formatted  processable  form.  This  is  intended  to  facilitate  the  reproduction  of  the  document  content  as 
intended  by  the  originator. 

This  clause  describes  the  layout  features  that  can  be  represented  in  documents  conforming  to  this  DAP. 
The  features  are  described  in  terms  that  are  typical  of  the  user-perceived  capabilities  and  semantics  found 
in  a  raster  document  interchange  environment. 

For  the  purpose  of  interchange,  a  document  is  represented  as  a  collection  of  constituents,  each  of  which 
is  represented  by  a  set  of  attributes.  The  constituents  that  make  up  a  formatted  document  are  defined 
below  in  this  clause  and  are  illustrated  in  figure  1 . 

Constituents  defined  as  required  must  occur  in  any  document  that  conforms  to  this  profile.  Constituents 
listed  as  optional  may  or  may  not  t>e  present  in  the  document,  depending  on  the  requirements  of  the 
particular  document. 

The  required  constituents  include: 

a)  a  document  profile; 

b)  layout  object  descriptions  representing  a  specific  layout  structure; 
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Document  Profile 


Presentation  Style 
(Optional) 


Specific  Layout 
Structure 


Content  Portion 
Description 


Figure  1  -  Constituents 


6.2      Logical  constituents 

Not  applicable. 


6.3      Layout  constituents 

This  clause  describes  the  features  of  the  layout  objects  that  can  be  represented  in  documents  conforming 
to  this  DAP. 


6.3.1       Overview  of  the  layout  characteristics 

The  document  structure  allows  the  document  content  to  be  laid  out  and  presented  in  one  or  more  pages. 
Each  page  in  a  document  consists  of  only  a  single  raster  graphics  content  representing  an  engineering 
drawing,  illustration,  or  other  raster  scanned  image. 

A  specific  layout  structure  of  the  document  conforming  to  this  application  profile  consists  of  a  four-level 
hierarchy  consisting  of  a  document  layout  root,  composite  pages,  frames,  and  blocks.  The  document  can 
consist  of  multiple  composite  pages  where  each  page  represents  a  single  image.  Each  composite  page 
consists  of  a  frame  which  in  turn  contains  a  block  containing  the  content  associated  with  the  image. 

Figure  2  is  an  illustration  of  the  features  of  the  document  layout  structure  supported  by  this  DAP. 


6.3.2  DocumentLayoutRoot 

A  DocumentLayoutRoot  is  the  top  level  in  a  document  layout  structure.  A  DocumentLayoutRoot  consists 
of  a  sequence  of  one  or  more  CompositePage  constituent  constraints. 
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Document 
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Figure  2  -  Document  layout  structure 


6.3.3       Page  characteristics 


Only  one  constituent  constraint  is  provided  to  present  pages  witliin  a  document. 

A  document  consists  of  a  sequence  of  one  or  more  composite  pages.  In  a  document's  composite  page, 
a  frame  Is  used  to  position  a  single  raster  graphics  content  representing  the  image  on  the  page. 

A  document  may  consist  of  multiple  pages  of  different  sizes.  Each  page  may  be  either  landscape  or  portrait 
orientation.  Both  orientations  are  permitted  in  the  document. 


6.3.3.1  CompositePage 

A  CompositePage  is  a  constituent  constraint  which  defines  a  composite  page  that  corresponds  to  the  page 
area  used  for  presenting  the  sequence  of  an  ImageFrame  frame. 


6.3.3.2        Page  dimensions 

A  wide  variety  of  page  dimensions  are  supported  including  large  format  raster  documents.  The  dimensions 
of  the  pages  may  be  specified  as  any  value,  in  BMU  measurement  units,  including  the  larger  sizes  produced 
from  foldout-size  images  and  roll  paper.  These  sizes  apply  to  both  portrait  and  landscape  orientations.  The 
page  sizes  include:  ISO  A0-A5,  ANSI  A-K,  Japanese  legal  and  letter,  foldouts  27.94  cm  (1 1  in.)  X  35.56  cm 
(14  in.)  and  27.94  cm  (11  in.)  X  43.18  cm  (17  in.),  and  27.94  cm  (11  in.)  roll  paper.  See  table  1. 

Dimensions  equivalent  to  or  less  than  the  common  assured  reproduction  area  (CARA)  of  ISO  A4  and  North 
American  Letter  (NAL)  in  portrait  or  landscape  orientation  are  basic  values.  Larger  page  sizes  including 
those  produced  from  roll  paper  are  non-basic  and  their  use  must  be  indicated  in  the  document  profile  (See 
table  2). 

The  default  dimensions  are  the  CARA  of  North  American  Letter  (A).  Any  default  page  dimensions  may  be 
specified  in  the  document  profile  subject  to  the  maximum  dimensions  defined  above  by  using  the  "page 
dimensions"  attribute.  The  "page  position"  attribute  may  be  used  to  specify  the  position  of  the  pel  array 
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image  on  the  page.  Although  actual  page  dimensions  may  be  used  allowing  for  the  raster  content  to 
completely  fill  a  page  leaving  no  tx>rders,  it  is  advised  that  the  assured  reproduction  area  (ARA)  listed  in 
table  1  t>e  used  wherever  feasible.  See  7.3  of  ISO  8613-2  for  general  rules  for  positioning  pages  on 
presentation  surfaces. 


6.3.3.3        Nominal  page  sizes 

The  nominal  page  sizes  that  may  t>e  specified  are  listed  in  table  1.  In  addition,  1 1  inch  roll  paper  of  any 
length  is  supported.  These  may  be  specified  in  portrait  or  landscape  orientations.  All  values  of  nominal 
page  size  are  non-basic  and  hence  all  values  used  in  a  document  must  t>e  indicated  in  the  document  profile 
using  the  "medium  type"  attribute  (See  table  2). 

Any  of  the  nominal  page  sizes  defined  in  table  1 ,  subject  to  the  restriction  specified  above,  may  be  specified 
as  the  default  value  in  the  document  profile. 

Table  1  also  includes  the  recommended  ARA.  Information  loss  may  occur  when  a  document  is  reproduced 
if  the  dimensions  of  the  CompositePage  exceed  the  ARA  for  the  specified  nominal  page  size. 


6.3.4  ImageFrame 

An  ImageFrame  is  a  constituent  constraint  which  defines  a  lowest  level  frame  used  for  laying  out  the  image 
of  an  engineering  drawing,  illustration,  or  other  raster  scanned  image.  This  frame  contains  a  single 
SpeclficBlock  containing  a  raster  graphics  content  portion.  Note  that  there  must  be  exactly  one 
ImageFrame  on  each  page  and  one  blocl<  in  the  frame. 

The  frame  has  a  fixed  position  that  is  equal  to  the  origin  of  the  page.  The  vertical  and  horizontal  dimensions 
of  this  frame  are  fixed  and  equal  to  the  maximum  size  that  can  be  achieved  for  the  position  within  the  area 
of  the  page. 


6.3.5  SpeciflcBlock 

A  SpeclficBlock  is  a  constituent  constraint  which  defines  a  basic  layout  object  used  to  position  and  image 
the  content  portions  associated  with  an  ImageFrame. 

The  position  of  the  block  is  fixed  and  defaults  to  the  origin  of  the  superior  frame.  The  dimensions  default 
to  the  maximum  size  that  can  be  achieved  for  the  position  within  the  area  of  the  superior  frame. 
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-  Dimensions  for  various  page  sizes 


Pag«  typ« 

Size 

Size  (BMU) 

ARA  (BMU) 

-  Metric 

IS0-A5 

148mm  X  210mm 

7015  x  9920 

not  defined 

IS0-A4 

210mm  X  297mm 

9920  x 14030 

9240  X  13200 

ISaA3 

297mm  x  420mm 

14030  X 19840 

13200  X  18480 

ISaA2 

420mm  x  594mm 

19840  x  28060 

18898  X  27118 

IS0-A1 

594mm  x  841mm 

28060  x  39680 

26173  x  37843 

ISO-AO 

841mm  X  1189mm 

39680  x  56120 

37843  X  54283 

-  ANSI,  North  American  (NA) 

NA-A 

8.5in  X  Ilin 

10200  x 13200 

9240  X  12400 

NA-B 

11  in  X  17in 

13200  X  20400 

12744  X 19656 

NA-C 

17in  X  22in 

20400  X  26400 

19500  X  25800 

NA-D 

22in  X  34in 

26400  x  40800 

25800  x  39600 

NA-E 

34in  X  44in 

40800  x  52800 

39600  X  52200 

NA-F 

28in  X  40in 

33600  x  48000 

32400  X  47400 

NA-G 

11in  X  90in 

13200  X  108000 

12400  X  106800 

NA-H 

28in  X  143in 

33600  X  171600 

31400  X  170400 

NA-J 

34in  X  176in 

40800  x  211200 

39600  x  210000 

NA-K 

40in  X  143in 

48000  X 171600 

47400  X  170400 

NA-Legal 

8.5in  X  14in 

10200  X 16800 

9240  X  15480 

-  Foldouts 

Small 

Ilin  X  14in 

13200  X 16800 

12744  X  15480 

NA-B 

Ilin  X  17in 

13200  X  20400 

12744  X 19656 

-  Japan 

Legal 

257mm  x  364mm 

12141  X 17196 

11200 X 15300 

Letter 

182mm  x  257mm 

8598  X 12141 

7600  X 10200 

Tutorial  Note  -  These  page  sizes  are  for  the  portrait  orientation. 
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Table  2  -  Layout  attributes 


Attributes 

Basic  values 

Default 
values 

Non-basic 
values 

Page  dimensions  ** 

CARA  NA  A. 
ISO  A4 

CARA  NA-A 

ARA  NA  B-K, 
ISO  A0-A3,Japan 
legal, 

11"  Roll  Paper 

Medium-type  ** 
(Nominal  page  size) 

None 

None 

NA  A-K, 
ISO  A0-A5, 
Japan  letter  & 
legal, 

11"  Roll  Paper 

Tutorial  Note  -  See  table  1  ** 


6.4      Document  layout  characteristics 

This  DAP  provides  only  for  formatted  documents.  Hence,  no  provision  is  made  for  constraining  the 
document  layout  process  other  than  as  implied  in  the  formatted  documents  supported  by  this  DAP.  In 
particular,  these  formatted  documents  are  characterized  by  the  following: 

a)  Documents  containing  only  composite  pages; 

b)  Documents  may  contain  one  or  more  pages; 

c)  Pages  may  vary  by  orientation  within  a  document; 

d)  Each  page  contains  a  single  raster  graphics  content  portion  representing  the  image; 

e)  Content  is  positioned  within  fixed  position  and  dimension  frames. 


6.5      Content  layout  and  imaging  control 

A  document  is  modelled  as  an  image  represented  by  a  raster  graphics  content  portion,  as  specified  in  ISO 
8613-7. 

The  only  content  architecture  that  may  be  specified  using  the  attribute  "content  architecture  class"  is 
formatted  processable  raster  graphics.  The  formatted  processable  raster  graphics  content  must  be  specified 
as  the  default  in  the  document  profile. 


10 


PART  23  -  ODA  Raster  DAP 


December  1992  (Stable) 


6.5.1 


Raster  graphics  content 


6.5.1.1 


Introduction 


This  clause  defines  the  features  that  are  applicable  to  the  raster  graphics  content. 
The  default  values  for  the  following  features  may  be  specified  in  the  document  profile: 

a)  type  of  coding  (required); 

b)  compression; 

c)  pel  path; 

d)  line  progression; 

e)  pel  spacing; 

f)  spacing  ratio. 

The  specification  in  a  document  of  a  non-basic  value  by  a  presentation  or  coding  attribute  must  be  indicated 
in  the  document  profile. 


6.5.1.2        Raster  graphics  content  architecture 

The  formatted  processable  raster  graphics  content  is  the  only  content  architecture  class  supported  by  this 
DAP  and  is  the  only  default  content  architecture  class  that  can  be  specified  in  the  document  profile. 

In  a  composite  page,  only  one  content  portion  can  be  associated  with  the  image. 


6.5.1.3        Raster  graphics  encoding  methods 

The  content  may  be  encoded  in  accordance  with  the  encoding  schemes  defined  in  CCITT 
Recommendations  T.4  and  T.6.  In  the  case  of  T.4,  either  the  one-dimensional  or  two-dimensional  encoding 
scheme  may  be  used.  Also  the  bitmap  encoding  scheme  defined  in  ISO  8613-7  may  be  used.  All  these 
forms  of  encoding  may  be  used  in  a  single  document  and  all  are  basic  values.  'Uncompressed'  mode  of 
encoding  may  also  be  used  but  only  as  a  non-basic  value. 

In  a  content  portion,  it  is  required  that  the  coding  attribute  "number  of  pels  per  line"  be  specified.  The 
coding  attribute  "number  of  lines"  may  also  be  specified.  No  restriction  is  placed  on  the  values  that  n^y 
be  specified  for  these  coding  attributes.  This  profile  places  no  constraints  on  the  size  of  the  pel  arrays  that 
may  be  used. 

The  type  of  coding  method  used  is  specified  by  the  attribute  "type  of  coding".  The  use  of  this  attribute  is 
mandatory  in  the  "document  architecture  defaults"  of  the  document  profile  to  define  the  default  value  of 
either  'T.6  encoding'  (untiled),  T.6  encoding  -  MSB'  (untiled),  or  'tiled  encoding'.  The  use  of  this  attribute 
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in  the  description  of  the  content  portions  is  non-mandatory.  If  this  attribute  is  not  specified  for  a  particular 
content  portion,  then  the  default  value  specified  In  the  "document  architecture  defaults"  of  the  document 
profile  is  used. 

If  the  tiled  encoding  method  is  used,  the  default  value  of  512  for  the  "number  of  pels  per  tile  line"  and 
"number  of  lines  per  tile"  must  be  used.  No  other  values  are  supported,  therefore  these  two  attributes  do 
not  need  to  be  specified,  if  the  "tile  types"  attribute  Is  not  present,  then  all  tiles  will  be  T.6  encoded.  If  it  is 
present,  then  there  must  be  a  value  specified  for  each  tile  in  which  case  only  'null  background',  'null 
foreground',  'T.6  encoded',  'T.6  encoded  -  MSB',  or  'bitmap  encoded'  values  are  supported.  The  T.4 
encodings  are  not  supported.  There  are  no  restrictions  on  the  use  of  the  "tiling  offset"  attribute  other  than 
that  specified  in  ISO  8613-7  Addendum. 

See  table  D.I,  Annex  D,  for  a  tabulated  list  of  the  attributes  and  their  basic,  default,  and  non-basic  values. 


6.5.1.4        Raster  presentation 

Raster  presentation  is  controlled  by  the  presentation  attributes  specified  in  ISO  8613-7.  This  DAP  provides 
for  additional  constraints  on  these  presentation  attributes  as  specified  below. 

The  basic  values  for  the  attribute  "pel  path"  supported  by  this  profile  are  0  and  90  degrees.  The  "pel  path" 
values  of  180  and  270  degrees  are  non-basic. 

The  basic  values  for  the  attribute  "line  progression"  supported  by  this  profile  is  270  degrees.  The  "line 
progression"  value  of  90  degrees  is  non-basic. 

Any  value  may  be  explicitly  specified  for  pel  spacing  provided  that  the  spacing  between  pels  is  not  less  than 
1  BMU.  The  pel  spacing  need  not  be  an  integer  value.  The  value  of  'null'  may  not  be  specified  because 
the  scalable  layout  process  is  not  supported.  The  specification  of  the  spacings  of  16,  12,  8,  6,  5,  4,  3,  2, 
and  1  BMU  between  adjacent  pels  are  iDasic.  The  specification  of  any  other  spacing  is  non-basic  and  must 
be  specified  in  the  document  profile. 

NOTES 

1  The  basic  pel  spacing  values  listed  above  are  equivalent  to  resolutions  of  75,  100, 150,  200,  240,  300,  400, 
600,  and  1200  pels  per  25.4mm  respectively  when  the  BMU  is  interpreted  as  1/1200  inch. 

2  The  attribute  'pel  spacing'  specifies  two  integers,  the  ratio  of  vt^ich  determines  the  pel  spacing.  No 
restriction  is  placed  on  the  values  of  these  integers. 

There  are  no  restrictions  on  the  use  of  the  "clipping"  attribute.  The  "image  dimensions"  attribute  is  not 
supported. 

There  are  no  restrictions  placed  on  the  value  of  the  "spacing  ratio"  attribute  providing  that  the  resultant  line 
spacing  is  not  less  than  1  BMU.  Also,  the  line  spacing  need  not  be  an  integral  number  of  BMUs.  Ail  values 
are  basic. 

See  table  D.2,  Annex  D,  for  a  tabulated  list  of  the  attributes  and  their  basic,  default,  and  non-basic  values. 
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6.6  Miscellaneous  features 

Specification  of  tiie  attribute  "application  comments"  is  optional.  When  used  in  conjunction  with  the  '^pe 
of  coding"  of  'tiled  encoding',  it  contains  a  sequence  of  positive  integers,  one  for  each  tile  in  the  content 
portion.  The  sequence  of  integers  is  a  set  of  indices  representing  the  octet  offsets  to  the  beginning  of  the 
respective  tiles,  starting  from  the  beginning  of  the  "content  information".  A  tiie  index  of  zero(0)  indicates  tfiat 
the  respective  tHe  is  null.  The  integers  will  be  sequenced  in  the  same  order  as  the  tiles.  The  tiles  will  t>e 
sequenced  primarily  in  the  pel  path  and  secondarily  in  the  line  progression  direction  as  defined  by  the 
presentation  attributes. 

6.7  Document  management  features 

Every  document  interchanged  in  accordance  with  this  DAP  must  include  a  document  profile  containing 
information  which  relates  to  the  document  as  a  whole. 

The  features  specified  by  the  document  profile  are  listed  below.  A  definition  of  the  information  contained 
in  these  features  is  given  in  the  corresponding  attribute  definitions  in  ISO  8613-4. 

Document  constituent  information: 

a)  specific  layout  structure; 

b)  presentation  styles  (optional). 
Document  characteristics: 

a)  document  application  profile; 

b)  document  application  profile  defaults; 

c)  document  architecture  class; 

d)  content  architecture  class; 

e)  interchange  format  class; 

f)  ODA  version  date; 

g)  raster  graphics  content  defaults. 
Non-basic  document  characteristics: 

a)  page  dimensions; 

b)  medium  type; 

c)  raster  graphics  presentation  features. 
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Dcx^ument  management  attributes: 

a)  document  description  (only  document  reference  supported). 
The  attributes  applicat>le  to  the  document  profile  are  defined  in  table  D.3,  Annex  D. 


7    Specification  of  constituent  constraints 


7.1      Document  profile  constraints 


7.1.1       Macro  definitions 

-  General  macros  - 
DEFINE(FDA,  "{'formatted'}") 

DEFINE(DAC,  "DocumentProfile  (Document-architecture-class)") 

DEFiNE(FPR."ASN.1{2  8  2  7  2}")  ~  Raster  formatted  processable  -- 

~  Basic  page  dimensions.  ~ 
DEFINE(BasicPageDimension,'' 

REQ  #horizontal-dimension  {REQ  #fixed-dimension  {  1..9240  }}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {  1.. 12400  }} 
I  REQ  #horizontal-dimension  {REQ  #fixed-dimension  {  1.. 12400  }}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {  1..9240  }} 
") 

-  Any  size  equal  to  or  smaller  than  CARA  (Common  Assured  Reproduction  Area)  of  ISO  A4  and  NA  A.  Both 
Portrait  and  Landscape  may  be  specified.  ~ 

-  Non-basic  page  dimensions.  - 
DEFINE(NonBasicPageDimensions," 

{REQ  #horizontal-dimension  {REQ  #fixed-dimension  {1.. 39680}}, 
REQ  #vertical-dimension  {REQ  #fixed -dimension  {12401. .56120}}} 
I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {9241  ..39680}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {1.. 56120}}} 

~  up  to  ISO  AO  portrait  ~ 
I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {1.. 56120}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {9241. .39680}}} 
I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {12401.. 561 20}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {1.. 39680}}} 

~  up  to  ISO  AO  landscape  - 
I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {1.. 48000}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {12401. .21 1200}}} 
I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {9241. .48000}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {1.. 21 1200}}} 
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-  up  to  ANSI  J/K  portrait  - 

I  {REQ  #horizontal-dimension  {REQ  #fixed-dlmenslon  {1..211200}}, 
REQ  #verticaI-dimension  {REQ  #fixed-dimenslon  {9241.. 48000}}} 
I  {REQ  #hori2ontal-dimension  {REQ  #fixed-dlmension  {12401  ..21 1200}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {1.. 48000}}} 

-  up  to  ANSI  J/K  landscape  -- 

I  {REQ  #hori2ontal-dimension  {REQ  #flxed-dimension  {1.. 12141}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {12401. .17196}}} 
1  {REQ  #horl2ontal-dlmension  {REQ  #fixed-dlmension  {9241. .12141}}, 
REQ  #vertical-dimension  {REQ  #flxed-dimension  {1.. 17196}}} 

-  up  to  Japanese  legal  portrait  - 

I  {REQ  #horizontal-dimension  {REQ  #fixed-dlmension  {1.. 17196}}, 
REQ  #vertical-dimenslon  {REQ  #fixed-dimenslon  {9241..12141}}} 
I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {12401..17196}}, 
REQ  #vertical-dimenslon  {REQ  #fixed-dlmension  {1.. 12141}}} 

--  up  to  Japanese  legal  landscape  ~ 
I  {REQ  #hori2ontal-dimension  {REQ  #fixed-dimension  {13200}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimenslon  {>=  16801}}} 
-  Any  portrait  size  larger  than  the  typical  foldout  size  (11  in  x  14  in)  including  11  inch  roll  paper.  - 
I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {>=  16801}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {13200}}} 

~  Any  landscape  size  larger  than  the  typical  foldout  size  (14  in  x  11  in)  including  11  inch  roll  paper  - 
") 

DEFINE(PermissiblePageDimensions," 

{REQ  #horizontal-dimension  {REQ  #fixed-dimension  {1.. 39680}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {1.. 56120}}} 

-  up  to  ISO  AO  portrait  -- 

I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {1.. 561 20}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {1.. 39680}}} 

--  up  to  ISO  AO  landscape  -- 
I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {1.. 48000}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {1.. 21 1200}}} 

-  up  to  ANSI  J/K  portrait  - 

I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {1.. 21 1200}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {1.. 48000}}} 

~  up  to  ANSI  J/K  landscape  - 
I  {REQ  #hori2ontal-dimension  {REQ  #fixed-dimension  {1.. 12141}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {1.. 17196}}} 

--  up  to  Japanese  legal  portrait  - 
I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {1.. 17196}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {1.. 12141}}} 
up  to  Japanese  legal  landscape  -- 

") 

DEFINE(NominalPageSizes," 

-  ISO  Page  Sizes  - 

REQ  #horizontal-dimension  {7015},  REQ  #vertical-dimension  {9920} 
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IS0A5 

REQ  #horizontal-dimension 

-  IS0A5 
REQ  #horizontal-dimension 

-  IS0A4 
REQ  #horizontal-dimension 

IS0A4 

REQ  #horizontal-dimension 

-  ISO  A3 
REQ  #horizontal-dimension 

-  ISO  A3 
REQ  #horizontal-dimension 

-  IS0A2 
REQ  #horizontal-dlmenslon 

--  IS0A2 
REQ  #horizontal-dimension 

-  IS0A1 
REQ  #horizontal-dimension 

--  IS0A1 
REQ  #horizontal-climenslon 
ISO  AO 

REQ  #hori2ontal-dimension 
--  ISO  AO 


December  1992  (Stable) 


ANSI  Page  Sizes  - 


Portrait  - 

{9920},  REQ  #vertical-dimension  {7015} 
Landscape  - 

{9920},  REQ  #vertical-dlmenslon  {14030} 
Portrait 

{14030},  REQ  #vertlcal-dimenslon  {9920} 
Landscape  - 

{14030},  REQ  #vertical-dimension  {19840} 
Portrait  - 

{19840},  REQ  #vertical-dimension  {14030} 
Landscape  - 

{19840},  REQ  #vertical-dimension  {28060} 
Portrait  -- 

{28060}.  REQ  #vertical-dinfienslon  {19840} 
Landscape  - 

{28060},  REQ  #vertical-dimension  {39680} 
Portrait  - 

{39680},  REQ  #vertical-dlmension  {28060} 
Landscape  - 

{39680},  REQ  #vertical-dimension  {56120} 
Portrait  -- 

{56120},  REQ  #vertical-dirDension  {39680} 
Landscape  - 


REQ  #horizontal-dimension  {10200},  REQ 
--  ANSI  A  Portrait  - 

REQ  #horizontal-dimension  {13200},  REQ 
--  ANSI  A  Landscape  -- 

REQ  #horizontal-dimension  {10200},  REQ 

-  ANSI  Legal  Portrait  - 
REQ  #horizontal-dimension  {16800},  REQ 

--  ANSI  Legal  Landscape 
REQ  #horizontal-dimension  {13200},  REQ 

-  ANSI  B  Portrait  -- 
REQ  #horlzontal-dimension  {20400},  REQ 

-  ANSI  B  Landscape  -- 
REQ  #hori2ontal-dimension  {20400},  REQ 

ANSI  C  Portrait  -- 
REQ  #  horizontal -dimension  {26400},  REQ 

--  ANSI  C  Landscape  -- 
REQ  # horizontal-dimension  {26400},  REQ 

~  ANSI  D  Portrait  ~ 
REQ  #horizontal-dimension  {40800},  REQ 

~  ANSI  D  Landscape  ~ 
REQ  #horizontal-dimension  {40800}.  REQ 

~  ANSI  E  Portrait  ~ 
REQ  #horizontal-dimension  {52800},  REQ 


#vertical-dimension  {13200} 
#vertical-dimension  {10200} 
#vertical-dimenslon  {16800} 
#vertical-dimenslon  {10200} 
#vertical-dimension  {20400} 
#vertical-dlmension  {13200} 
#vertical-dimension  {26400} 
#vertical-dimension  {20400} 
#vertical-dimension  {40800} 
#vertical-dimension  {26400} 
#vertical-dimension  {52800} 
#vertical-dimension  {40800} 
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-  ANSI  E  Landscape  - 

I  REQ  #horl2ontal-dimension  {33600},  REQ  #vertical-dimension  {48000} 

-  ANSI  F  Portrait  - 

I  REQ  #horizontal-dimension  {48000},  REQ  #vertical-dlmension  {33600} 

-  ANSI  F  Larxjscape  - 

I  REQ  #horl2ontal-dlmension  {13200},  REQ  #vertical-dlmenslon  {108000} 
--  ANSI  G  Portrait 

I  REQ  #horlzontal-dimension  {108000},  REQ  #vertical-dimension  {13200} 

-  ANSI  G  Landscape  - 

I  REQ  #horl2ontal-dimension  {33600},  REQ  #vertlcal-dimenslon  {171600} 

--  ANSI  H  Portrait  - 
I  REQ  #horlzontal-dimension  {171600},  REQ  #vertical-dimenslon  {33600} 

-  ANSI  H  Landscape  ~ 

I  REQ  #horizontal-dinfiension  {40800},  REQ  #vertlcal-dimension  {211200} 
ANSI  J  Portrait  - 

I  REQ  #hori2ontal-dimension  {211200},  REQ  #vertlcal-dimension  {40800} 

--  ANSI  J  Landscape  -- 
!  REQ  #horizontal-dimension  {48000},  REQ  #vertical-dimension  {171600} 

-  ANSI  K  Portrait  - 

I  REQ  #horizontal-dimension  {171600},  REQ  #vertical-dimension  {48000} 

-  ANSI  K  Landscape  -- 

--  Foldouts  -- 

I  REQ  #horlzontal-dimension  {13200},  REQ  #vertical-dimension  {16800} 

--  Fddout  Portrait  -- 
I  REQ  # horizontal-dimension  {16800},  REQ  #vertical-dimension  {13200} 

-  Foldout  Landscape  - 

I  REQ  #horizontal-dimension  {13200},  REQ  #vertical-dimension  {>=  16801} 

-  Any  portrait  size  larger  than  the  typical  foldout  size  (11  in  x  14  in)  including  1 1  inch  roll  paper  - 
I  REQ  #horizontal-dimension  {>=  16801},  REQ  #vertical-dimension  {13200} 

-  Any  landscape  size  larger  than  the  typical  foldout  size  (14  in  x  1 1  in)  including  1 1  inch  roll  paper  - 


7.1.2 


Constituent  constraints 


7.1.2.1 


DocumentProfile 


{ 


-  Presence  of  document  constituents  -- 


REQ  Specific-layout-structure 
PERM  Presentation-styles 


{'present'}, 
{'present'}, 


~  Document  characteristics  ~ 
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REQ     Document-application-profile    {-  See  clause  8  for  a  definition  of  the  permitted  values  for 

this  attribute.  --}, 

REQ     Document-application-profile-defaults  { 

~  Docunfient  architecture  defaults  ~ 


REQ 

PERM 

PERM 


#content-architecture-class 

#dimensions 

#medium-type 

PERM  # nominal-page-size 

PERM  #side-of-sheet 


{$FPR}. 

{$PermissiblePageDimensions}, 
{ 

{$NominalPageSizes}, 
{ANY  VALUE}}, 


~  Any  permitted  medium  type.  Both  landscape  and  portrait  may  be  specified. 


REQ  #type-of-coding 


{ASN.1  {28370}--  T6  encoding  ~ 
I  ASN.1  {283  75}--  tiled  encoding  ~ 
I  ASN.1  (28376}  ~  T6  encoding  -  MSB  ~  }. 
{ANY  VALUE}, 


PERM  #page-position 

PERM  raster-graphics-contents-defaults  { 

PERM  #pel-path  {ANY  VALUE}, 

PERM  #line-progression         {ANY  VALUE}, 
PERM  #pel-spacing  {REQ  #length  {ANY  VALUE}, 

REQ  #pel-spaces  {ANY  VALUE}}, 

PERM  #spacing-ratio 

{REQ  #line-spacing-value        {ANY  VALUE}. 

REQ  #pel-spacing-value         {ANY  VALUE}}, 
PERM  #compression  {ANY  VALUE}}. 


REQ 
REQ 
REQ 


REQ 


Document-architecture-class 
Content-architecture-classes 
Interchange-format-class 


ODA-version 

{REQ  #standard-or-recommendation 
REQ  #publication-date 


{$FDA}, 
{$FPR}, 

{--  This  attribute  required  only  for  ODIF 
intercfiange.  See  clause  8  for  a  definition  of  the 
permitted  value  for  this  attribute.  --}, 


{'ISO  8613'}. 
{'1991-12-31'}}, 

~  This  date  represents  the  date  that  this  DAP  was  approved.  This  is  the  only 

-  approved  value,  however,  the  date  will  be  changed  if  the  DAP  is  significantly 
~  revised.  If  the  date  is  revised,  use  of  the  new  date  is  required  only  when  the 

-  additional  functionality  is  being  used.  That  is,  legacy  products  may  continue  to 

-  support  the  earlier  DAP. 


Non-t}asic  document  characteristics  - 

PERM  Page-dimensions 

PERM  Medium-types 

PERM  #nominal-page-size 
PERM  #side-of-sheet 


{MUL  {$NonBasicPageDimensions}}, 
{MUL{ 

{$NominalPageSizes}, 
{ANY_VALUE}}}. 
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-  All  values  of  "medium  type"  are  non-basic  ~ 
PERM  Coding-attributes  { 

REQ  #raster-graphics-coding-attributes  { 

REQ  #compression  {'uncompressed'}}}. 


PERM  Presentation-features  { 

PERM  #Raster-graphics-presentation-features 


PERM 

PERM 
PERM 


PERM 


#pel-path 

#line-progression 
#pel-spacing 


{  MUL  { 
{'180-degrees'  | 
'270-degrees'} 
{'90-degrees'} 

{REQ  #length  {ANY  VALUE} 
EXCEPT  {16.12.8,6.5.4.3,2,1}. 
REQ  #pel-spaces  {ANYVALUE} 
EXCEPT 
{1}} 


#spacing-ratio 

{REQ  #line-spacing-value 

REQ  #pel-spacing-value 


{ANY  VALUE}  EXCEPT 
{1}. 

{ANY  VALUE}  EXCEPT 
{1}}}}}. 


~  Document  management  attributes  ~ 
-  Document  description  ~ 

REQ  Document-reference  {ANY  VALUE} 

} 

7.2  Logical  constituent  constraints 

No  logical  constituents  applicable  in  this  clause. 

7.3  Layout  constituent  constraints 
7.3.1       Macro  definitions 

DEFINE(RAST,"  CONTENTJD_OF(Raster-graphics-content-portion)") 
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7.3.2 


Factor  constraints 


FACTOR 


ANY-LAYOUT 


SPECIFIC: 

PERM  Object-type 

REQ  Object-identifier 

PERM  Subordinates 

PERM  User-visibie-name 

PERM  User-readable-comments 

} 


{VIRTUAL}, 
{ANYVALUE}, 
{VIRTUAL}, 
{ANYVALUE}, 
{ANY  VALUE} 


7.3.3       Constituent  constraints 


7.3.3.1  Documenti-ayoutRoot 

DocumentLayoutRoot:  ANY-LAYOUT  { 


SPECIFIC: 

REQ  Object-type 

REQ  Subordinates 

} 


7.3.3.2 


CompositePage 


CompositePage: 

SPECIFIC: 
REQ  Object-type 
REQ  Sutx)rdlnates 
PERM  Dimensions 
PERM  Page-position 
PERM  Medium-type 

PERM  Application-comments 


{  'document-layout-root'}. 
{SUB  ID  OF(CompositePage)  +  } 


ANY-LAYOUT  { 


{'page'}. 

{SUBJD_OF(lmageFrame)}, 

{$PermlssiblePageDimensions}, 

{ANY_VALUE}, 

{PERM  #nominal-page-size  {$NominalPageSlzes}, 
PERM  #side-of-sheet  {ANY_VALUE}}, 
{ANY  VALUE} 


7.3.3.3  ImageFrame 

ImageFrame:  ANY-LAYOUT  { 


SPECIFIC: 

REQ  Object-type 

REQ  Subordinates 

PERM  Application-comments 


{'frame'}, 

{SUBJD_OF(SpecificBlock)}, 
{ANY  VALUE} 
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} 


7.3.3.4  SpecificBlock 

SpecificBlock 

SPECIFIC: 
REQ  Object-type 
REQ  Ot)ject-identlfier 
REQ  Content-portions 
PERM  Position 

PERM  Dimensions 


PERM 
PERM 
PERM 
PERM 

PERM 

PERM 


} 


Content-arciiitecture-dass 
User-readat)le-comments 
User-visible-name 
Application-comments 

Presentation-style 

~  PStyte  for  raster  content 

Presentation-attributes 

PERM  #raster-graphics-attributes 
PERM  #pel-path 
PERM  #line-progression 
PERM  #pel-spacing 

PERM  #spacing-ratio 

PERM  #clipping 


{'block'}. 

{ANY_VALUE}. 

{$RAST}. 

{REQ  #fixed-positk>n  { 

REQ  #horizontal-position  {ANY  VALUE}, 

REQ  #vertteal-posltlon  {ANY  VALUE}}}. 
{REQ  #liorizontal-dlmensk>n 

{REQ  #fixed-dimension{ANY_VALUE}}. 
REQ  #vertical-dimension 

{REQ  #fixed-dimensk>n{ANY  VALUE}}}. 

{$FPR}. 

{any  string}. 
{any|;string}. 
{anyvalue}, 

~  See  8. 1.3  and  8.2.3- 
{STYLEJD_^OF(PStyle)}. 


{ 


{ 


{ANY_VALUE}. 

{ANY_VALUE}. 

{REQ  #length  {ANY  VALUE}, 

REQ  #pel-spaces  {ANY  VALUE}}, 

{REQ  #line-spacing-value  {ANY  VALUE}, 

REQ  #pel-spacing-value  {ANY  VALUE}}. 

{ANY_VALUE}}} 


7.4     Layout  style  constraints 

No  layout  style  constraints  applicable  in  this  clause. 
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7.5.1  Macro  definitions 

No  macro  definitions  are  applicabie  to  this  dause. 

7.5.2  Factor  constraints 

FACTOR  ANY-PRESENTATION-STYL£  { 

REQ    Presentation-styte-identlfier  {ANY  VALUE}, 

PERM  User-readable-comments  {ANY~STRING}. 
PERM  User-visible-name  {ANY~STRING} 

7.5.3  Presentation  style  constituent  constraint 
7.5.3.1  PStyle 

PStyle:  ANY-PRESENTATION-STYLE  { 

~  Tills  style  is  used  for  raster  graphics  content  ~ 

PERM  Presentatton-attributes  { 
PERM  #raster-graphics-attribiJtes  { 

PERM  #pel-path  {ANY  VALUE}, 

PERM  #line-progression        {ANY  VALUE}. 
PERM  #pel-spacing  {REQ  #length  {ANY  VALUE}. 

REQ  #pei-spaces  {ANY  VALUE}}, 
PERM  #spaclng-ratio  {REQ  #line-spaclng-value  {ANY  VALUE}. 

REQ  #pel-spacing-value  {ANY  VALUE}}. 
PERM  #clipping  {ANY  VALUE}}} 

} 

7.6     Content  portion  constraints 
7.6.1       Macro  definitions 

DERNE(TILED."         ASN.1  {2  8  3  7  5}")  -  Tiled  raster  encoding  - 
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7.6.2  Factor  constraints 

No  fector  constraints  are  appiicat)le  to  this  dause. 

7.6.3  Constituent  constraints 


7.6.3.1 


Raster  graphics  content  portion 


Raster-graphics-content-portion 
REQ  Content-identifier-layout 
PERM  Type-of-coding 


{ 


{ANY 
{ASK 
I  ASN 
I  ASN 
I  ASN 
1  ASN 
I  ASN 
I  ASN 
I  ASN 


VALUE}, 

;i{2  8  3  70}  - T.6 encoding - 

.1{283  7  1}  - T.4 orw dimensional - 

.1  {2  8  3  7  2}  -  T.4  two  dimensional  ~ 

.1  {2  8  3  7  3}  -  bitmap  encoding  - 

1{2  83  75}  ~ tiled  encoding  ~ 

.1  {2  8  3  7  6}  -  T.6  encoding  -  MSB  - 

1{2  8  3  7  7}  ~  T.4  one  dimensional  •  MSB  - 

1  {2  8  3  7  8}  ~  T.4  two  dimensional  -  MSB  -  }, 


PERM  Coding-attrit>utes  { 
REQ     #raster-graphics-coding-attributes  { 

PERM  #compression  {ANY_VALUE}. 
PERM  #number-of-lines  {>0}, 
REQ    #number-of-pels-per-line  {>0}, 
CASE  Raster-graphics-content-portion  (Type-of-coding)  OF  { 


{$TiLED}: 


{PERM  #number-of-pels-per-tile-line  {512}. 


PERM  #number-of-lines-per-tile 
PERM  #tiiing-offset 
PERM  #tile-types 


PERM 
PERM 
} 


Alternative-representation 
Content-information 


{ANYSTRING}. 
{RASTER} 


{512}. 

{ANYVALUE}. 
{'null  background'  | 
'null  foreground'  | 
T.6  encoded'  | 
'bitmap  encoded'  | 
T.6  encoded  -  MSB'}}}}. 
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8     Interchange  format 

Two  interchange  fomr^ts  are  supported  by  this  profile.  The  interchange  fomiat  ODIF  (class  A)  can  be  used 
by  applications  requiring  a  binary  encoding  t>ased  on  ASN.1.  The  Interchange  Fonnat  SDIF  can  be  used 
by  applications  requiring  a  SGML  t>ased  clear  text  encoding.  This  latter  interchange  fonnat  is  an  SGML 
application,  called  Office  Document  Language  (ODL).  For  the  purposes  of  interchange,  the  ODL  ENTITIES 
are  placed  in  an  ASN.1  wrapper,  as  defined  by  SDIF.  Each  encoding  form  has  inherent  advantages. 
Conversion  of  document  encoded  in  one  interchange  format  into  the  other  should  not  produce  the  loss  of 
semantic  document  information. 


8.1      Interchange  format  ODIF  (class  A) 


8.1.1       Interchange  format 

The  value  of  the  document  profile  attribute  "interchange  format"  for  this  interchange  format  is  'if-a'.  This  form 
of  ODIF  is  deflned  in  ISO  8613-5. 

The  encoding  is  in  accordance  with  the  Basic  Encoding  Rules  for  Abstract  Syntax  Notation  One  (ASN.1), 
as  defined  in  ISO  8825. 


8.1.2       DAP  identifier 

The  value  for  the  document  profile  attribute  "document  application  profile"  for  this  interchange  format  is 
represented  by  the  following  object  identifier. 

iso  (1)  identified-organization  (3)  oiw  (14)  odasig  (11)  image-appi  (1)  raster-dap-odif  (1) 


8.1.3       Encoding  of  application  comments 

ISO  8613-5  define  the  encoding  of  the  attribute  "application  comments"  as  an  octet  string.  For 
SpecificBlocl<,  this  DAP  requires  that  the  encoding  within  that  octet  string  t>e  in  accordance  with  the  ASN.1 
syntax  specified  in  the  following  module  definition. 

NIST-DAPSpecification 

DEFINITIONS  ::=  BEGIN 

EXPORTS  Object-Appl-Comm-Encoding; 

Object-Appl-Comm-Encoding  ::=  SEQUENCE  OF  INTEGER 
END 
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8.2      Interchange  format  SDIF 


8.2.1       Interchange  format 

The  document  profile  attribute  "interchange  format"  does  not  apply  for  this  interchange  format.  The  SDIF 
encoding  of  ODA  Is  defined  in  Annex  E  of  ISO  8613-5.  In  addition,  ISO  8613-7  contains  additional 
specifications  for  this  encoding  of  ODA. 


8.2.2       DAP  identifier 

The  value  for  this  attribute  "document  application  profile"  for  this  interchange  format  is  represented  by  the 
following  object  identifier. 

iso  (1)  identified-organization  (3)  oiw  (14)  odasig  (11)  image-appi  (1)  raster-dap-sd'rf  (2) 


8.2.3       Encoding  of  application  comments 

For  SpeciflcBlock,  the  encoding  of  the  attribute  "application  comments"  Is  defined  in  a  data  stream 
conforming  to  this  profile  with  the  following  DTD  definition: 

<  l~  The  following  set  of  declarations  may  be  invol<ed  by  using  a  public  entity  as  follows: 

<  IDOCTYPE  odaac  Public  "-//USA-OIW//DTD  SGIVIL  ENCODING  ODA  APPUCATION  COMMENTS//EN"> 

-> 

<!--  NOTE:  To  parse  the  following  Document  Type  Declaration  Subset,  place  the  Document  Type 
declaration"  < IDOCTYPE  odaac  ["  at  the  beginning  of  the  file  and  "]>"  at  the  end  of  the  file.  ~> 

<!  ELEMENT  odaac  -  -  (objappc)+  > 

<!~  Object  application  comment  ~> 

<  ELEMENT  objappc  -  0  (#PCDATA)> 

8.3      Encoding  of  raster  content  information 

The  encoding  of  raster  content  information  in  the  bitmap  encoding  scheme  is  that  specified  in  9.3  of  the 
raster  graphics  content  architecture  part  of  ISO  8613-7,  that  is,  the  first  pel  in  the  order  of  bits  is  allocated 
to  the  most  significant  bit  of  an  octet.  The  encoding  of  the  code  words  in  the  CCITT  Recommendation  T.4 
and  T.6  encoding  schemes  may  be  done  in  either  the  up  or  down  bit  order.  The  bit  order  is  specified  by 
the  attributes  "type  of  coding"  or  "tile  types".  The  attribute  "tile  types"  is  used  only  when  the  value  for  "type 
of  coding"  is  'tiled  encoded'.  For  the  up  order,  it  is  such  that  the  first  or  only  bit  of  the  first  code  word  shall 
be  placed  in  the  least  significant  bit  of  the  first  octet.  Subsequent  bits  of  the  first  and  following  code  words 
are  placed  in  the  direction  of  more  significant  bits  in  the  first  and  following  octets.  For  the  down  order,  it 
is  such  that  the  first  or  only  bit  of  the  first  code  word  shall  be  placed  in  the  most  significant  bit  (MSB)  of  the 
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first  octet.  Subsequent  bits  of  the  first  and  following  code  words  are  placed  in  the  direction  of  least 
significant  bits  in  the  first  and  following  octets. 
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Annex  A  (normative) 
Amendments  and  corrigenda 

A.1  Amendments 

A.1.1      Amendments  to  the  base  standard 

The  amendments  applicable  to  this  DAP  includes  the  ISO  8613  -  Amendment  1:  1990.  This  amendment 
includes  text  to  be  included  in  ISO  8613-1  as  the  following  annexes: 

a)  Annex  E:  Use  of  ISO/IEC  10021  (MOTIS)  to  interchange  documents  conforming  to  ISO  8613; 

b)  Annex  F:  Document  application  profile  proforma  and  notation; 

c)  Annex  G:  Conformance  testing  methodology; 

d)  Annex  H:  Recording  of  documents  conforming  to  ISO  8613  on  flexible  disk  cartridges 
conforming  to  ISO  9293. 

In  addition,  this  amendment  addresses  the  inclusion  of  the  ISO  8613  Technical  Corrigenda  1. 

This  DAP  does  not  include  the  following  features  of  the  amendment: 

a)  Addendum  on  security; 

b)  Addendum  on  styles; 

c)  Addendum  on  alternative  representation. 

Additionally,  this  DAP  includes  features  from  the  Tiled  Raster  Graphics  Addendum  to  ISO  8613-7,  ISO/IEC 
JTC1/SC18/WG5  901.  dated  September  1990,  and  the  Additional  Bit  Order  Mapping  Addendum  to  CCITT 
Rec.  T.417I  ISO  8613-7.  ISO/IEC  JTC  1/WG  3,  dated  July  1991.  A  new  version  of  ISO  8613-7  which  also 
will  incorporate  the  Colour  Addendum  is  scheduled  to  be  issued  in  1993. 

A.2  Corrigenda 

A.2.1       Corrigenda  to  this  DAP 
There  are  no  corrigenda  to  this  DAP. 
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Annex  B  (informative) 
Recommended  practices 


B.I      Transfer  methods  for  ODA  ; 

B.1.1       Conveyance  of  ODA  over  CCITT  X.400-1984 

This  recommendation  describes  how  ODA  body  parts  are  to  be  encoded  for  transmission  over  a  CCITT 
X.400-1984  service. 

An  ODA  body  part  is  encoded  as  OdaBodyPart  in  the  definition  given  below: 


OdaBodyPart  ::=  SEQUENCE  {  OdaBodyPartParameters,  OdaData  } 
OdaBodyPartParameters  ::=  SET  { 
document-application-profile 

[0]  IMPLICIT  OBJECT  IDENTIFIER, 
document-architecture-class 

[1]  IMPLICIT  INTEGER  { 
formatted  (0), 
processable  (1), 
fornriatted-processable  (2)  } 
OdaData  ::=     SEQUENCE  OF  Interchange-Data-Element 


NOTE  -  It  is  recommended  to  transfer  an  ODA  document  as  a  single  body  part  with  tag  12: 
Oda  [12]  IMPLICIT  OCTETSTRING 

The  content  of  the  octet  string  is  encoded  as  OdaBodyPart,  defined  above.  hHowever,  this  Is  out 
of  the  scope  of  this  profile. 


B.1.2       Conveyance  of  ODA  over  FTAM 

This  recommerKlation  describes  the  File  Transfer,  Access,  and  Management  (FTAM)  Document  Type  to  be 
used  for  minimal  storage  and  transfer  capabilities  of  ODA  data  streams.  It  is  recognized  that  enhanced 
capabilities  may  at  some  point  be  added. 

When  using  FTAM  to  transfer  an  ODA  file,  the  FTAM-3,  "ISO  FTAM  Unstructured  Binary",  document  type 
should  be  specified.  IHowever,  since  files  that  do  not  contain  ODA  data  streams  can  have  the  same 
document  type,  it  is  left  up  to  the  user  of  application  programs  that  remotely  access  files  using  FTAM  to 
l<now  that  a  given  file  contains  an  ODA  data  stream. 
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B.I. 3      Conveyance  of  ODA  over  DTAM 

This  recommendation  provides  for  information  concerning  the  interchange  of  ODA  based  documents  with 
Document  Transfer  and  Manipulation  (DTAM)  protocols. 

DTAM  is  defined  in  the  T.430-Series  of  recommendations  and  is,  Wke  ODA.  an  integral  part  of  the  T.400- 
Series  of  CCITT  Recommendations  named  Open  Document  Architecture,  Transfer  and  Manipulation. 

The  T.520-Series  of  recommendations  contain  Communication  Application  Profiles  (CAP).  Recommendation 
T.522  describes  the  Communication  Application  Profile  BT1  for  document  bdk  transfer.  Recommendation 
T.522  is  applicable  for  the  Office  Document  Format  Profile  (POD)  published  in  this  ISP. 

NOTE  -  The  use  of  BT1  within  the  end-to-end  oriented  Telematic  Services  Telefax  4  and  Teletex  is  described 
in  7.1  of  Recommendation  T.561  and  7.1  of  Recommendation  T.562. 


B.1.4      Conveyance  of  ODA  over  flexible  disks 

The  recommended  method  for  interchanging  ODA  documents  between  systems  by  the  exchange  of 
magnetically  recorded  Rexibie  DisIc  Cartridges  is  by  the  use  of  an  annex  to  ISO  8613-1  (to  be  published), 
Receding  of  Documents  Conforming  to  ISO  8613  on  Flexible  Cartridges  Conforming  to  ISO  9293.  This 
annex  provides  for  recording  each  ODA  document  as  a  separate  file  as  defined  by  ISO  9293,  Volume  and 
File  Structure  of  Flexible  Disk  Cartridges  for  Information  Interchange. 

NOTE  -  Document  encoded  in  OOL  can  be  stored  such  that  each  SGML  ENTITY  is  recorded  in  a  separate 
file  or  in  the  case  of  an  SDIF  encoding,  the  file  can  be  stored  in  a  single  file. 

B.2     Interoperability  with  SGML  applications 

The  recommended  method  for  the  exchange  of  documents  between  Standard  Generalized  Markup 
Language  (ISO  8879,  SGML)  based  systems  and  systems  based  on  this  ODA  document  application  profile 
is  by  means  of  exchanging  a  document  representation  conforming  to  these  agreements  in  an  encoded  form 
of  the  SGML  language  l<nown  as  the  Office  Document  l-anguage  (ODL).  ODL  is  a  standardized  SGML 
application  for  representing  documents  conforming  to  the  ODA  base  standard.  Such  a  representation  can 
be  converted  into  the  Office  Document  Interchange  Format  (ODIF)  supported  by  this  document  application 
profile. 
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References  to  other  standards  and  registers 

CCnr  Recommendation  T.400  :  1988.  Introduction  to  Document  Architecture,  Transfer  and  Manipulation; 

CCm  Recommendation  T.411  :  1988,  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Introduction  and  Gerieral  Principles; 

CX^  Recommendation  T.412  :  1988.  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Document  Structures; 

CCnr  Recommendation  T.414  :  1988.  Open  Document  Architecture  (ODA)  and  interchange  Fomwt: 
Document  Profle; 

CCITT  Recommendation  T.415  : 1988.  Open  Document  Architecture  (ODA)  and  Interchange  Format:  Open 
Document  Interchange  Format; 

CCITT  Rec(xnmendation  T.417 : 1988.  Open  Document  Architecture  (ODA)  and  Interchange  Format:  Raster 
Graphics  Content  Architecture; 

CCITT  Recommendation  T.503 : 1 984.  Document  Application  Profile  for  the  interchange  of  Group  4  Facsimle 
Documents; 

ISO  8571  : 1988,  information  processing  systems  -  Open  Systems  interconnection  -  FHe  transfer,  access  and 
management; 

ISO  9070 : 1990,  Information  processing  -  SGML  support  tecHities  -  Registration  procedures  for  public  owner 
identifiers; 

ISO/TR  9573  :  1988.  Information  processing  -  SGML  technical  report  -  Techniques  for  using  SGML; 

ISO  10021  :  (to  be  published),  Information  processing  systems  -  Text  communication  -  Message  Oriented 
Text  Interchange  System; 

ISP  FOD26  :  (to  be  published).  Office  document  fonnat  profile  for  the  interchange  of  enhanced  function 
mixed  content  documents  in  processabie  and  formatted  forms; 

ISP  FOD36  :  (to  be  published).  Office  document  format  profile  for  the  interchange  of  extended  function 
mixed  content  documents  in  processat)le  and  formatted  forms; 

MIL-R-28002A  :  1990.  MIUTARY  SPECIFICATION.  RASTER  GRAPHICS  REPRESENTATION  IN  BINARY 
FORMAT.  REQUIREMENTS  FOR. 


December  1992  (Stable) 
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Annex  D  (informative) 

Supplementary  information  on  attributes 


Table  D.I  -  Content  coding  attributes 


AttributM 

Basic  values 

Default  values 

Non-t>asic  1 
values  1 

Number-of-pels-per-line 

£uiy  positive  integer 

None 

None 

Numb€r-of-|jnes 

any  positive  integer 

None 

None 

Tiling-offset* 

(any  non-negative  integer 
<  512,  any  non-negative 
integer  <  512) 

(0.0) 

None  1 

Tile-types* 

T.6  encoded,  bitmap 
encoded,  null 
background,  null 
foreground,  T.6  encoded  - 
MSB 

T.6  encoded 

None  1 

Type-of-coding 

T.6  encoding  (untiled), 
bitmap  (untiled),  tiled 
encoded,  T.4  ID 
encoding,  T.4  2D 
encoding,  T.6  encoding  - 
MSB  (untiled),  T.4  ID 
encoding  -  MSB,  T.4  2D 
encoding  -  MSB 

T.6  encoding,  T.6 
encoding  -  MSB,  tiled 
encoding  ** 

None  1 

Tutorial  Note  -  *  Only  used  if  type  of  coding'  is  'tiled  encoded' 


Tutorial  Note  -  **  As  specified  in  the  document  profile 


Table  D.2  -  Presentation  attributes 


Attributes 

Basic  values 

DefauK  values 

Non-basic  values 

Pel-path) 

0,  90  deg 

0  deg 

180,  270  deg 

Line-progression 

270  deg 

270  deg 

90  deg 

Pel-spacing 

16,  12,  8,  6,  5.  4,  3,  2,  1 
BMU 

4  BMU  (300) 

Any  value  except 
'null' 

Clipping 

Two  Coordinate  Pairs 
(any  non-negative  integer, 
any  non-negative  integer) 

(0,0).  (N-1.  L-1) 

None 
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AIII1DUIO 

Class 

—  ^   1 

Peimissible  vaSues  1 

^Sv^^M^JSa-I Aft  j^Va  a4  xiftrji  a^'At  tiPA 

opscmOHfiQ^oui-struotiire 



presem  i 

riv8ornanon-8iyi68 

nm 

presem 

uocuiirain-cnaraciensiics 

M 

Oocument-architecture-dass 

m 

formatted 

Document-application-proftie 

m 

{-  See  clause  8  for  a  definition  of  the 
permitted  values  for  this  attribute.  -} 

Content-architecture-classes 

m 

{28272} 

Interchange-fbrmat-class 

m 

A 

ODA-versiort 

m 

ISO  8613.  1991-12-31 

Document-architecture-defautts 

M 

Corttent-architef^re-ciass 

m        \  formatted  processable  raster  graphics  1 

Type-of-coding 

m          T.6  encoding,  tiled  encoding,  T.6  | 
1  encoding  -  MSB  | 

Page-dimensions 

nm 

See  list  In  table  1,  (Default  value  is  NA-  1 
A.  9240  X  13200  BMU)  | 

1  Medium- types 

nm 

See  list  in  table  1,  (Default  value  is  NA-  1 
A,  9240  X  13200  BMU)  1 

Page-position 

nm 

any  coordinate  pair  within  page 

Raster-gr-content-defaults 

NM 

Pel-path 

nm 

0,  90,  180,  270  degrees  (0  is  normal 
default) 

1  Line-progression 

nm 

90,  270  degrees  (270  is  normal  defeiult) 

Pel-spacing 

nm 

16, 12,  8,  6  5,  4,  3,  2,  1  BMU,  (Normal 
deteult  is  4  BMU) 

Spacing  Ratio 

nm 

Any  value 

Non-basic-doc-characteristics 

NM 

Page-dimensions 

nm 

See  table  1 

Medium-types 

nm 

See  table  1  | 
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 Table  D.3  -  Document  profile  atlribmet  (conduded)  


Attribute 

Class 

Psrmlsslble  values 

Raster-gr-presentatiorvfeatures 

NM 

Pel-path 

nm 

180,  270  degrees 

Line-progression 

nm 

90  degrees 

Pel-spacing 

nm 

Any  value  except  16. 12,  8,  6,  5,  4,  3,  2. 

or  1  BMU 

Docunnent-management-attributes 

M 

Document  Reference 

m 

Any  string  of  characters 

The  following  notation  is  used  in  the  class  column  of  this  table: 

a)  m  mandatory  attribute 

b)  nm  non-mandatory  attribute 

c)  d  defeultable  attribute 

Capital  letters  (M,  NM,  and  D)  are  used  for  groups  of  attributes. 
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Annex  E  (informative) 


Register  index 

 Table  E.I  -  Object  identmers 


Object  identifiM- 

Reference 

iso  (1)  identified-organization  (3)  oiw  (14)  odasig  (11) 
image-appi  (1)  raster-dap-odif  (1) 

8.1.2 

iso  (1)  identified-organization  (3)  oiw  (14)  odasig  (11) 
image-appi  (1)  raster-dap-sdif  (2) 

8.2.2 
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Foreword 

This  part  of  tlie  Stable  Implementation  Agreements  was  prepared  by  the  Conformance  Testing  Special 
Interest  Group  (CTSIG)  of  the  Open  Systems  Environment  Implementors'  Worl(shop  (OIW). 

Text  in  this  part  has  been  approved  by  the  Plenary  of  the  above-mentioned  Worl<shop. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  a  new 
part.  Deleted  and  replaced  text  will  be  shown  as  struci<.  New  and  replacement  text  will  be  shown  as 
shaded. 
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Part  24  -  Conformance  Testing 

0  Introduction 

(Refer  to  Working  Implementation  Agreements  Document) 

1  Scope 

(Refer  to  Working  Implementation  Agreements  Document) 

2  Normative  References 

(Refer  to  Working  Implementation  Agreements  Document) 

3  Status 

This  material  is  current  as  of  December  18,  1992. 

4  Errata 

Errata  will  t>e  reflected  in  replacement  pages  of  Version  6,  Stat>le  Document. 

5  Guidelines  on  Interpretation  of  Disputed  Test  Cases 

(Refer  to  Working  Implementation  Agreements  Document) 

6  Guidelines  on  the  Choice  of  PICS 

(Refer  to  Working  Implementation  Agreements  Document) 
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7     CT  SIG  Resolution  for  FTAM 

(Refer  to  Working  Implementation  Agreements  Document) 


3    Guidelines  for  PCTR  Test  Campaign  Summary 

Tlie  following  table  provides  guidelines  for  handling  tlie  "selected",  "not  run"  and  "observations"  columns  in 
a  Protocol  Conformance  Test  Report.  In  the  following  table,  the  "criterion"  column  in  tal<en  with  the  "test  case 
^tus"  column  to  give  the  expected  contents  of  the  three  PCTR  columns.  Note  that  this  table  does  not 
contain  all  possible  permutations  of  PICS  support  answer,  lUT  behavior,  and  test  case  status.  The  primary 
focus  of  this  table  is  to  provide  PCTR  guidelines  for  the  permutations  of  "test  case  status". 
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Table  1  -  Guidelines  for  the  use  of  the  "Selected"  and  "Not  Run"  columns  in  a  PCTR 


Criterion                                                            PCTR               PCTR  PCTR 

selected           not  run  observation 
column             column  column 

1.   TEST  DESELECTED 

1.  feature  not  implemented 

deselect 

<  empty  > 

<  empty  >  (f) 

2.  feature  not  applicable 

deselect 

<  empty  > 

<empty> 
(f) 

II.  TEST  SELECTED:  TEST  PURPOSE 

NOT  ACHIEVED 

1 .  ATS  defect;  no  error 
in  standard 

select 

not  run 

(g) 

ATS  error 
(a.c) 

2.  ATS  defect;  error  or 
ambiguity  in  standard 

select 

not  run 

(g) 

ATS  error 
(a.c) 

3.  ETS  defect 

select 

not  run 
(9) 

ETS  error 
(a.b,c) 

4.   No  defect;   Inconclusive  verdict 

select 

run 

manual 
analysis 
(c.d) 

III.  TEST  SELECTED;  TEST  PURPOSE  ACHIEVED 

1 .  Test  is  defect-free 

select 

run 

<  empty> 
(e) 

2.  ETS/ATS  defect; 
workaround  available 

select 

run 

manual 
analysis 
alternate 
verdict 
(b,c,d) 

See  Notes  listed  below: 

a)  This  criteria  includes  any  test  where  the  test  purpose  cannot  t>e  achieved  by  an  iUT  exhibiting 
valid  behavior. 

b)  This  criteria  includes  any  test  where  the  ETC  attempts  to  accomplish  the  test  purpose  in  an 
overly  restrictive  way,  resulting  in  an  Inconclusive  test  case  verdict,  even  though  the  IUT  exhibits 
valid  behavior.  Manual  analysis  instructions  are  provided  by  the  MOT  supplier  for  such  tests.  These 
Instructions  are  used  by  the  test  lab  to  determine  whether  the  test  purpose  can  be  achieved.  If  the 
analysis  shows  that  the  test  purpose  cannot  be  achieved,  the  PCTR  indicates  this  test  as  "Not  Run". 
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If  the  analysis  shows  that  the  test  purpose  can  be  achieved,  the  PCTR  indicates  this  test  as  "Run". 

c)  The  Observation  must  include  tlie  MOT  supplier's  Defect  Report  numt)er  or  a  reference  to  official 
MOT  documentation  (such  as  the  release  notes  or  test  specifications)  or  conective  action.  If  the 
MOT  supplier  does  not  agree  that  the  test  case  is  defective,  then  the  observation  must  include  a 
standard  and/or  profile  justification,  if  the  defect  is  iUT  specific,  the  obsen/ation  must  include  a 
test^-specMc  Justification,  or  a  reference  to  one.  The  observation  must  fully  and  adequately  explain 
why  the  lUTs  behavior  is  valid. 

d)  The  Obsen/ation  must  include  a  test-specific  justification  of  verdict.  Analysis  of  IUT  behavior 
reveals  no  evidence  of  non-conformance  and  no  l<now  impact  on  intenA^orking.  Manual  analysis 
also  reveals  no  evidence  of  ATC/ETC  defect. 

e)  An  observation  is  needed  only  if  the  test  case  verdict  in  not  Pass. 

f)  It  is  recommended  tliat  the  observation  column  contain  a  reference  to  the  test  case  selection 
expression  used  to  de-seiect  the  test  case.  If  the  observation  column  is  empty  for  a  particular  item, 
which  has  been  de-selected,  the  default  meaning  is  that  the  item  was  de-selected  leased  on  the 
PICS.  If  the  test  is  deselected  for  PiXIT  reasons,  the  reference  is  mandatory. 

g)  The  term  "not  run'  as  used  here  is  not  the  normal  English  usage  of  the  term.  See  ISO/IEC 
9646-5  for  the  meaning  of  the  "run"  column  of  the  PCTR.  When  "not  run"  appears  in  the  run  column 
of  the  PCTR  it  indicates  a  situation  in  which  there  is  an  ATS  or  ETS  error. 
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Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Health  Care  Special  Interest  Group 
(HCSIG)  of  the  Open  Systems  Environment  Implementors'  Workshop  (OIW). 
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part.  Deleted  arxi  replaced  text  will  be  shown  as  struck.  New  arxJ  replacement  text  will  be  shown  as 
shaded. 
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Part  25  -  Health  Care 


Editor't  Note  -  This  part  is  reserved  for  future  stable  Health  Care  agreements.  These  agreements  may  be 
found  In  the  aligned  part  of  the  Working  Implementation  Agreements  document.  When  tfiese  agreements 
become  stable,  they  will  be  moved  into  Part  25. 
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Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Open  Systems  Environment 
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part  with  rediine  (shaded)  for  next  text  and  stikeout  (— )  for  deleted  text. 
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Edttor's  Note  -  Text  for  the  Level  2  to  Level  3  Migration  DAP  will  be  moved  here  from  the  Working 
Agreements  whenever  it  t>ecomes  stable. 
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This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Directory  Services  Special 
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Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as 
change  pages.  Deleted  and  replaced  text  will  be  shown  as  strikeout.  New  and  replacement  text  will 
be  shown  as  shaded. 
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Editor's  Note  -  This  part  is  reserved  for  future  stable  text  relating  to  the  1 993  Edition  Directory  Services 
Protocols.  Refer  to  the  aligned  section  of  the  Working  Document. 
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♦  U.S.  G.P.0.:1993-341-931:82606 


ANNOUNCEMENT  OF  NEW  PUBLICATIONS  ON 
COMPUTER  SYSTEMS  TECHNOLOGY 


Superintendent  of  Documents 
Government  Printing  Office 
Washington,  DC  20402 


Dear  Sir: 

Please  add  my  name  to  the  annoimcement  list  of  new  publications  to  be  issued  in 
the  series:  National  Institute  of  Standards  and  Technology  Special  Publication  500*. 

Name  

Company  

Address  '.  

City  State  Zip  Code_  


(Notiflcatioa  key 


I 


I 


i  < 


llJLkjM.  Technical  Publications 

Periodical 


Journal  of  Research  of  the  National  Institute  of  Standards  and  Technology— Reports  NIST 
research  and  development  in  those  disciplines  of  the  physical  and  engineering  sciences  in  which 
the  Institute  is  active.  These  include  physics,  chemistry,  engineering,  mathematics,  and  computer 
sciences.  Papers  cover  a  broad  range  of  subjects,  with  major  emphasis  on  measurement 
methodology  and  the  basic  technology  underlying  standardization.  Also  included  from  time  to  time 
are  survey  articles  on  topics  closely  related  to  the  Institute's  technical  and  scientific  programs. 
Issued  six  times  a  year.  , 


Nonperiodicals 


Monographs— Major  contributions  to  the  technical  literature  on  various  subjects  related  to  the 
Institute's  scientific  and  technical  activities. 

Handbooks  —  Recommended  codes  of  engineering  and  industrial  practice  (including  safety  codes) 
developed  in  cooperation  with  interested  industries,  professional  organizations,  and  regulatory 
bodies. 

Special  Publications  — Include  proceedings  of  conferences  sponsored  by  NIST,  NIST  annual 
reports,  and  other  special  publications  appropriate  to  this  grouping  such  as  wall  charts,  pocket 
cards,  and  bibliographies. 

Applied  Mathematics  Series  —  Mathematical  tables,  manuals,  and  studies  of  special  interest  to 
physicists,  engineers,  chemists,  biologists,  mathematicians,  computer  programmers,  and  others 
engaged  in  scientific  and  technical  work. 

National  Standard  Reference  Data  Series  —  Provides  quantitative  data  on  the  physical  and  chemical 
properties  of  materials,  compiled  from  the  world's  literature  and  critically  evaluated.  Developed 
under  a  worldwide  program  coordinated  by  NIST  under  the  authority  of  the  National  Standard 
Data  Act  (Public  Law  90-396).  NOTE:  The  Journal  of  Physical  and  Chemical  Reference  Data 
(JPCRD)  is  published  bimonthly  for  NIST  by  the  American  Chemical  Society  (ACS)  and  the 
American  Institute  of  Physics  (AIP).  Subscriptions,  reprints,  and  supplements  are  available  from 
ACS,  1155  Sixteenth  St.,  NW.,  Washington,  DC  20056. 

Building  Science  Series  — Disseminates  technical  information  developed  at  the  Institute  on  building 
materials,  components,  systems,  and  whole  structures.  The  series  presents  research  results,  test 
methods,  and  performance  criteria  related  to  the  structural  and  environmental  functions  and  the 
durability  and  safety  characteristics  of  building  elements  and  systems. 

Technical  Notes— Studies  or  reports  which  are  complete  in  themselves  but  restrictive  in  their 
treatment  of  a  subject.  Analogous  to  monographs  but  not  so  comprehensive  in  scope  or  definitive 
in  treatment  of  the  subject  area.  Often  serve  as  a  vehicle  for  final  reports  of  work  performed  at 
NIST  under  the  sponsorship  of  other  government  agencies. 

Voluntary  Product  Standards  — Developed  under  procedures  published  by  the  Department  of 
Commerce  in  Part  10,  Title  15,  of  the  Code  of  Federal  Regulations.  The  standards  establish 
nationally  recognized  requirements  for  products,  and  provide  all  concerned  interests  with  a  basis 
for  common  understanding  of  the  characteristics  of  the  products.  NIST  administers  this  program 
in  support  of  the  efforts  of  private-sector  standardizing  organizations. 

Consumer  Information  Series  — Practical  information,  based  on  NIST  research  and  experience, 
covering  areas  of  interest  to  the  consumer.  Easily  understandable  language  and  illustrations 
provide  useful  background  knowledge  for  shopping  in  today's  technological  marketplace. 
Order  the  above  NIST  publications  from:  Superintendent  of  Documents,  Government  Printing  Office, 
Washington,  DC  20402. 

Order  the  following  NIST  publications— FIPS  and  NISTIRs—from  the  National  Technical  Information 
Service,  Springfield,  VA  22161. 

Federal  Information  Processing  Standards  Publications  (FIPS  PUB)  —  Publications  in  this  series 
collectively  constitute  the  Federal  Information  Processing  Standards  Register.  The  Register  serves 
as  the  official  source  of  information  in  the  Federal  Government  regarding  standards  issued  by 
NIST  pursuant  to  the  Federal  Property  and  Administrative  Services  Act  of  1949  as  amended, 
Public  Law  89-306  (79  Stat.  1127),  and  as  implemented  by  Executive  Order  11717  (38  FR  12315, 
dated  May  11,  1973)  and  Part  6  of  Title  15  CFR  (Code  of  Federal  Regulations). 
NIST  Interagency  Reports  (NISTIR)— A  special  series  of  interim  or  final  reports  on  work 
performed  by  NIST  for  outside  sponsors  (both  government  and  non-government).  In  general, 
mitial  distribution  is  handled  by  the  sponsor;  public  distribution  is  by  the  National  Technical 
Information  Service,  Springfield,  VA  22161,  in  paper  copy  or  microfiche  form. 
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